Re: Severe regression in autoconf 2.61

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I am not sure this explains the BSD case.  NetBSD/BSDi uses
> > fsetpos/fgetpos to implement fseeko/ftello.
> 
> What exactly do you mean by "uses" --- are fseeko and ftello declared
> as macros that call the other two, or what?

There are ftello/ftello implementions in our port/fseeko.c;  prototypes
are in our include/port.h.

> I'd kinda have thought that the new coding of AC_FUNC_FSEEKO would
> work well with macros.  What it *doesn't* work well, or at all,
> with is
> 
>     #ifdef _LARGEFILE_SOURCE
>     extern int fseeko(...
>     #endif
> 
> which is exactly what the test was originally supposed to find out
> about :-(
> 
> > I don't really understand why ac_cv_sys_largefile_source is now being
> > tested.
> 
> I think the idea is that by this point, ac_cv_sys_largefile_source is
> set to 1 if you need _LARGEFILE_SOURCE to see a definition of fseeko
> (as above), or to "no" if you see a definition of fseeko without
> _LARGEFILE_SOURCE, or to "unknown" if you don't get fseeko either way.
> So that test makes sense in context.  The problem is that someone
> subsequently broke the method for testing whether fseeko is declared.

OK, based on the way they are doing things now I can't inject a
ac_cv_sys_largefile_source=no from outside that function so the BSD*
workaround I just did is necessary, and probably less prone to breakage.

Have you see these lines lower in configure.in?
if test $ac_cv_func_fseeko = yes; thenAC_SYS_LARGEFILEfi

Is this broken too?  

It just seemed more straight-forward when the defined HAVE_FSEEKO based
on ac_cv_func_fseeko rather than ac_cv_sys_largefile_source.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +