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. +