_FILE_OFFSET_BITS=64 with fcntl.h causes build problems with open64 defines
I'm getting a problem when setting _FILE_OFFSET_BITS=64 on the command line. Here's a test case:
class test
{
void open(constint);
};
#include <fcntl.h>
void test::open (constint){}
and here's the output:
[b]CC -D_FILE_OFFSET_BITS=64 -c open.cpp
"open.cpp", line 8: Error: open64(const int) is not a member of test.
[/b]
So including fcntl.h is causing open to be replaced with open64 in the function implementation only, breaking the code. This happens with both 32 and 64 bit builds on 64 bit Linux (RHEL4)
This is happening via a line in /usr/include/fcntl.h:
#define open open64
This redefine does not happen with g++402 or the Intel compiler, so I traced through the headers and here's what I found:
fcntl.h includes features.h which does this:
#if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64
# define __USE_FILE_OFFSET641
#endif
features.h then includes sys/cdefs.h which does:
#if defined __GNUC__ && __GNUC__ >= 2
# define __REDIRECT(name, proto, alias) name proto __asm__ (__ASMNAME (#alias))
...
then back in fcntl.h after the above is this:
#ifndef __USE_FILE_OFFSET64
...
#else
# ifdef __REDIRECT
...
#else
# define open open64
# endif
#endif
So the open64 define is hit if we have both _FILE_OFFSET_BITS=64 and __REDIRECT unset. The latter happens if __GNUC__ is undefined.
The crucial difference with the Intel and GNU compilers is that both of these define __GNUC__, which causes __REDIRECT to be defined and so avoids the open64 define. The Sun compiler by default does not define __GNUC__
Given the above, I am not sure where the problem lies.
Firstly I am not clear on what "gcc compatability" means in reference to the Sun compiler. Is there a document explaining exactly what it is? I searched around a bit, but did not find anything. Should the Sun compiler be defining __GNUC__ to get this, the same way the Intel compiler does? Or should we not expect any code that is inside this macro to be available to us? Is there a compiler flag that enables this macro during compiles?
If none of the above, can I define __GNUC__ myself or am I risking a world of pain?
Is this really a problem with the gcc headers themselves? The #define in fcntl seems a very nasty piece of code.
And if all the above fail, is there an alternative fix for my problem?
Given the above I didn't want to log this as a bug without getting more input.
Thanks.
Martin
