here's the mail that was originally sent to the autoconf group just after I had been portint my zziplib 0.10.77 into the mixmode world to support both 32bit and 64bit models with the same library code. That description is not complete but should help you quite a bit:
* The library problem ... As you see, the AC_SYS_LARGEFILE call will make these binaries to be linked with different symbols compiled into the base libraries (glibc here). That is easily achieved by specific forms in the header files of the C library which boils down to #if !defined _LP64 && _FILE_OFFSET_BITS+0 == 64 #define lseek lseek64 #endif and the glibc maintainers have ensured that any call to (32bit type) lseek will be converted into a call to the actual lseek64, simply because the underlying unix kernel uses 64bit fileoffsets natively, it's just that some arguments have to be checked. In effect, the library exports two lseek symbols: $ objdump -T /lib/libc.so.6 | grep " lseek" 000bf9a0 w DF .text 0000003d GLIBC_2.0 lseek 000cba90 w DF .text 00000088 GLIBC_2.1 lseek64 * Third party libraries.... While this sounds logical, how would you guide a developer of a third-party library to support this dual-mode off_t field. And how can autoconf support it actually. First of all, the AC_SYS_LARGEFILE macro is a bit short-sighted - it does simply enable 64bit off_t but it does so on either freebsd system where this is native and on linux system where it is optional. However, on linux system we want the 64bit variant of library calls to be named slightly differently. http://ac-archive.sf.net/guidod/ac_sys_largefile_sensitive.html has been build on top of it to AC_DEFINE an extra symbol called LARGEFILE_SENSITIVE which guides the library maker to the knowledege that this system is actually off_t/off64_t sensitive. In the header file of his library, he may write now: #if defined LARGEFILE_SENSITIVE && _FILE_OFFSET_BITS+0 == 64 #define my_seek my_seek64 #define my_open my_open64 #endif An application linking to the library will now be made to link with the *64 variants, and the library itself will provide them if being compiled as a largefile variant. If the application and library are both in 32bit then they will also link correctly, but when they mismatch... then the linkage will fail, i.e. ld: my_open not found and doing a grep on the system table of the library will reveal a symbol my_open64. * Combined exports... this scheme can be extended however - when the library sources detect a LARGEFILE_SENSITIVE system and that it is being compiled as _LARGEFILE_SOURCE then it can choose to export a catch-call symbol as well. off_t my_lseek (int fd, off_t offs, int whence) { ..... } #if defined LARGEFILE_SENSITIVE && _FILE_OFFSET_BITS+0 == 64 #undef my_lseek /* has been diverted to my_lseek64 */ long my_lseek (int fd, long offs, int whence) { off_t off = my_lseek64 (fd, offs, whence); offs = off; if (offs != off) { errno=EOVERFLOW; return -1; } return offs; } #endif * Conclusions.... Well, what do you want - the 32bit off_t in a largefile unix98 is definitly a bad choice from the beginning. It is always questionable whether it is good choice to extend the lifetime of this nuisiance. On the other hand, there is sometimes the need to create and maintain a library that may be regarded as a "base library" for many programs and which should therefore support the ability to -Define an off_t type and size.