Paul Eggert schrieb:
Guido Draheim <[EMAIL PROTECTED]> writes:
I am using AC_SYS_LARGEFILE AC_CHECK_FUNCS(ftello fseeko)
Use AC_FUNC_FSEEKO rather than AC_CHECK_FUNCS(fseeko). That should work around your problems.
Thanks. However, that macro still calls the glibc behavior a bug, which I think is simply true. The glibc cvs stdio.h should be fixed, - atleast do export fseeko when #def __USE_FILE_OFFSET64 is set!! - just in order to avoid that silent callframe-mismatch. In other words, export the REDIRECT atleast when a redirect-call is required to make things to function properly.
This mode is easily achieved, in the glibc stdio.h part on fseeko: delete the __USE_LARGEFILE ifdefs within the #else-part opened by that #ifndef __USE_FILE_OFFSET64.
This minimal change is strictly required unless glibc maintainers like to see the next program to delete some large database with an innocent fseeko call of a software ported to lfs mode running on a glibc system. Note that C compilers wouldn't even warn about the missing fseeko declaration unless -Wall or similar was given.
# AC_FUNC_FSEEKO # -------------- AC_DEFUN([AC_FUNC_FSEEKO], [_AC_SYS_LARGEFILE_MACRO_VALUE(_LARGEFILE_SOURCE, 1, [ac_cv_sys_largefile_source], [Define to 1 to make fseeko visible on some hosts (e.g. glibc 2.2).], [EMAIL PROTECTED]:@include <stdio.h>], [return !fseeko;])
# We used to try defining _XOPEN_SOURCE=500 too, to work around a bug
# in glibc 2.1.3, but that breaks too many other things.
# If you want fseeko and ftello with glibc, upgrade to a fixed glibc.
AC_CACHE_CHECK([for fseeko], [ac_cv_func_fseeko],
[AC_LINK_IFELSE([AC_LANG_PROGRAM([EMAIL PROTECTED]:@include <stdio.h>],
[[return fseeko && fseeko (stdin, 0, 0);]])],
[ac_cv_func_fseeko=yes],
[ac_cv_func_fseeko=no])])
if test $ac_cv_func_fseeko = yes; then
AC_DEFINE(HAVE_FSEEKO, 1,
[Define to 1 if fseeko (and presumably ftello) exists and is declared.])
fi
])# AC_FUNC_FSEEKO