Using the testscripts we find that
most Linux/Solaris distributions contain broken builds - as they
import both off32_t symbols and off64_t symbols. Also
there are some reports with people using autoconf
AC_SYS_LARGEFILE
but they still get
a broken build (or no largefile binary at all).
The reason: on a 64on32 largefile sensitive system you do need to have a C preprocessor #define to exist before any #include of a system header. Most global include headers will somehow include the libc headers, so depending on the order you may or may not get the 32bit symbols or the 64bit symbols for file access to be linked into your program.
Especially, this is a problem for BIG projects - some subproject may have used the --enable-largefile correctly but the other did not; yet they are linked very closely with each other thereby passing filepointers back and forth. The common errors are:
-D_FILE_OFFSET_BITS=64
preprocessor definition. The old KDE plugin system headers did
even mess with a structure
mismatch using off_t in its exported structures but they were
not defending against different sizes for this entity.
AC_SYS_LARGEFILE
and
AC_CONFIG_HEADER
then the relevant
definitions of the first macro will only be present in
the config header file specified in the second macro - it will
not be added to CPPFLAGS or any other Makefile variable
modifying the C compiler commandline. Most people think that config.h
is just an optional header file carrying hints to be evaluated
locally but that is different for
_FILE_OFFSET_BITS
which is being
evaluated in the system header files on 64on32 largefile sensitive
systems.
The situation is very very very dangerous - because big projects are often used by many applications that build upon them but opensource big projects have higher probability to errornously create a broken build by adding third party code. A testscript check on Suse-10.0 (January 2006) reveals these broken builds:
libblkid.so.1.0 libext2fs.so.2.4 libGL.so.1.0.7676 libgcj.so.6.0.0 libmono.so.0.0.0 libmonodebuggerserver.so.0.0.0 libnetpbm.so.10.26 libnspr4.so libquicktime.so.0.0.0 libtcl8.4.so
These may corrupt multi-gigabyte data files all on their own.
(mono and java runtimes are usually broken due to libgc
configure.in without ac_sys_largefile. Many others have some configfile
library to read *.ini files which happen to be very short unless
hacked)
Hint: it can help to modify the toplevel makefile adding-D_FILE_OFFSET_BITS=64
toCC
orCPPFLAGS
as a non-optional definition. Enforcing largefile support prevents broken builds atleast locally and contemporary systems are largefile-ready anyway. If you do use autotools then you can get the same result withCPPFLAGS="$CPPFLAGS -D_FILE_OFFSET_BITS=64"