Broken Builds

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:

• Plugins for a File Explorer do often have their own Makefiles that may or may not contain the relevant -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.
• Recursive Makefiles with a subproject included form a third party that did enable off64_t but the toplevel Makefile did not enable it for the rest of the project. That can both be a sub-configure in a subdirectory or just a Makefile in a subdirectory that was copied from somewhere else. Some big projects even had problems with some developer to enable largefile support and the other did not but their work was linked into a single library.
• Autoconf "config.h" needs to be included in all *.c files as the first line. In other words, if you do use both 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 to CC or CPPFLAGS 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 with

     CPPFLAGS="$CPPFLAGS -D_FILE_OFFSET_BITS=64"