Building with -D_FILE_OFFSET_BITS=64 uses names that should be in the user's namespace. For example, #include <stdio.h> #include <stdlib.h> void fopen64 (void) { abort (); } int main (void) { fopen ("/dev/null", "r"); return 0; } built with -std=c99 -D_FILE_OFFSET_BITS=64 on x86 aborts. All the function redirects for _FILE_OFFSET_BITS=64 should be to functions in the implementation namespace. This applies to POSIX interfaces as well as to ISO C ones.
This issue has been bothering me for a long time too, but I never thought to report it. The only solution I see is to rename all the *64 functions to __*64 and update the headers accordingly. Of course aliases would need to be kept with the old names, and _LARGEFILE64_SOURCE would need to expose the old names. Solving the problem also has the unfortunate consequence that newly-linked binaries will depend on a new glibc even if they otherwise would have worked with very old versions. Nonetheless, I agree that something should be done about this bug. Using _FILE_OFFSET_BITS=64 is the only viable configuration on a modern system. (A mixed system with some binaries compiled with 32-bit offsets and others with 64-bit offsets has dangerous issues with file descriptor inheritance; see bug #13047.) And it seems a real shame for the only viable configuration to be non-conformant in this regard.
On Mon, 14 May 2012, bugdal at aerifal dot cx wrote: > This issue has been bothering me for a long time too, but I never thought to > report it. If you have any issues with glibc that can be represented as well-defined bugs - specific deficiencies for which it can be clearly assessed whether they have been fixed - and they don't have currently open bugs, please open (or reopen) bugs for them. It doesn't matter how minor or obscure or hard to fix they are, we should track bugs in the bug database. They may not be fixed particularly quickly - the existing bug backlog may take person-years of work across many people to deal with - but they should be filed so they are visible to people looking for bugs to fix. (More open-ended projects for enhancement that don't represent a well-defined defect in current glibc may better go on the wiki than in Bugzilla; there are "Project TODO" and "Project Wishlist by Developer" sections there linking to pages with various suggestions.)