autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#401377: autoconf: AC_FUNC_FSEEKO does not make fseeko()/ftello()


From: Paul Eggert
Subject: Re: Bug#401377: autoconf: AC_FUNC_FSEEKO does not make fseeko()/ftello() visible
Date: Mon, 04 Dec 2006 15:57:11 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Ralf Wildenhues <address@hidden> writes:

> This looks like a regression to me

Yup, me too.  Thanks for reporting it.

> It seems the problematic bit here is this part of the change:
> |        * lib/autoconf/functions.m4 (AC_FUNC_FSEEKO): Don't compile the
> |        fseeko testing program twice; just use the earlier result.

I don't see why that is the problem.  If the earlier compilation
thinks fseeko is present when it actually is absent, isn't that a bug?
(Please see a related question below.)

> -   address@hidden:@include <stdio.h>],
> -   [[return fseeko (stdin, 0, 0) && (fseeko) (stdin, 0, 0);]])
> +   address@hidden:@include <stdio.h>], [typedef int (*fp);
> +                          fp p = (fp) fseeko;
> +                          return !p;])

This doesn't look right.  It's the same as saying 'int *fp = (int *) fseeko;';
surely you meant a function type instead.  But with that change, it's
a good idea.

>  # 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.
> -if test $ac_cv_sys_largefile_source != unknown; then
> +AC_CACHE_CHECK([for fseeko], [ac_cv_func_fseeko],
> +[AC_LINK_IFELSE([AC_LANG_PROGRAM(address@hidden:@include <stdio.h>],
> +                              [[return 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

Sorry, I don't see why this part of the change is relevant.  The
current code tries to link fseeko, so why would the second test report
anything differently from the first?

I installed the following, which implements the idea of the first part
of your patch, I hope in a better way.

2006-12-04  Paul Eggert  <address@hidden>

        * lib/autoconf/functions.m4 (AC_FUNC_FSEEKO): Check that fseeko
        can be assigned to a function pointer.  Problem reported by
        Peter Palfrader in <http://bugs.debian.org/401377>.  Based on
        part of a patch by Ralf Wildenhues in that same bug report.

Index: lib/autoconf/functions.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/functions.m4,v
retrieving revision 1.116
diff -p -u -r1.116 functions.m4
--- lib/autoconf/functions.m4   28 Nov 2006 03:29:48 -0000      1.116
+++ lib/autoconf/functions.m4   4 Dec 2006 23:47:42 -0000
@@ -587,8 +587,10 @@ 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).],
-   address@hidden:@include <stdio.h>],
-   [[return fseeko (stdin, 0, 0) && (fseeko) (stdin, 0, 0);]])
+   [[#include <sys/types.h> /* for off_t */
+     #include <stdio.h>]],
+   [[int (*fp) (FILE *, off_t, int) = fseeko;
+     return fseeko (stdin, 0, 0) && fp (stdin, 0, 0);]])
 
 # 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]