bug-glibc
[Top][All Lists]
Advanced

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

ac_sys_largefile / fseeko problem


From: Guido Draheim
Subject: ac_sys_largefile / fseeko problem
Date: Mon, 17 Mar 2003 02:19:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826

I am using
AC_SYS_LARGEFILE
AC_CHECK_FUNCS(ftello fseeko)

Later in the source files, I have some

#include "config.h"
#include <stdio.h>
#ifdef HAVE_FTELLO
#define _ftell ftello
#else
#define _ftell ftell
#endif

When configuring, I see...

checking for unistd.h... (cached) yes
checking for off_t... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for _LARGE_FILES value needed for large files... no
checking for ftello... yes
checking for fseeko... yes


When I compile these sources on mdk9.0 / glibc 2.2.5
then the compiler will choke and say...

../../../pfe/block-sub.c: In function `p4_reposition_file':
../../../pfe/block-sub.c:151: warning: implicit declaration of function `fseeko'
../../../pfe/block-sub.c: In function `p4_resize_file':
../../../pfe/block-sub.c:237: warning: implicit declaration of function `ftello'

REASON:
  AC_SYS_LARGEFILE will make off_t a 64bit value.
  In glibc feature.h it triggers __USE_FILE_OFFSET64

  This will map all open/seek/tell functions to their
  64bit counterpart open64/seek64/ftello64

  It would also map fseeko/ftello to fseeko64/ftello64.
  But it does not do so unless somekind of largefile
  bit has been set also. This is beyond expectations
  of the macro-name AC_SYS_LARGEFILE atleast.

  The largefile bit (in contrast to off_t=64bit) can be
  set through some unix98 bit or gnu_source bit. That
  is not done during autoconf - the autoconf macro
  will do a link-check, and since libc has the symbol,
  it does succeed.

PROBLEM:
  Here is the real hammer with this:

  the gcc "implicit symbol" is only a warning!! The compiler
  will in fact walk over it, and complete comiling. The gcc
  even link the final binary. However, it will link to some
  "asm fseeko", it will not redirect-link to "asm fseeko64"
  as it should since sizeof(off_t) == 64bit !!!

  Result: callframe mismatch for fseeko calls.

SOLUTIONS:
  declare fseeko unconditionally of a unix98 bit. If is
  in the library, then it should get a prototype.

  Modify sys_largefile to actually enable largefile mode
  in the sense that glibc is able to understand.

  Modify glibc feature, when 64bit off_t is selected,
  export fseeko prototypes. A compromise that is.

Other comments?

-- cheers, guido         http://ac-archive.sf.net/largefile

appendix: a test project.

-- configure.ac
AC_INIT(fseeko-problem.c)
AC_LANG_C
AC_PROG_CC
AM_INIT_AUTOMAKE(fseek-problem, 0.1)
AM_CONFIG_HEADER(config.h)
AC_LIBTOOL_DLOPEN
AC_LIBTOOL_WIN32_DLL
AM_PROG_LIBTOOL
AC_PROG_INSTALL
AC_TYPE_OFF_T
AC_SYS_LARGEFILE
AC_CHECK_FUNCS( fseeko ftello )
test ".$GCC" = ".yes" && CFLAGS="$CFLAGS -Wall"
AC_OUTPUT(Makefile)

-- Makefile.am
AUTOMAKE_OPTIONS = foreign
AUTOTOOL_VERSION = autoconf-2.52 automake-1.5 libtool-1.4.2
bin_PROGRAMS = fseeko-problem

-- fseeko-problem.c
#include "config.h"
#include <sys/types.h>
#include <stdio.h>

int main(int argc, char** argv)
{
    off_t size;
    FILE* f = fopen(argv[0], "r");
#  ifdef HAVE_FSEEKO
    fseeko (f, 0, SEEK_END);
    size = ftello (f);
#  else
    fseeko (f, 0, SEEK_END);
    size = ftell (f);
#  endif
    return size;
}








reply via email to

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