[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_SYS_LARGEFILE
From: |
Paul Eggert |
Subject: |
Re: AC_SYS_LARGEFILE |
Date: |
Thu, 10 Jan 2002 22:29:06 -0800 (PST) |
> From: Peter Simons <address@hidden>
> Date: Wed, 9 Jan 2002 20:39:03 +0100
>
> I recently added AC_SYS_LARGEFILE macro to my configure scripts, but I
> encountered an interesting problem on Solaris 8: The configure script
> adds the define "_FILE_OFFSET_BITS=64" to my CPPFLAGS, but once it
> does, <unistd.h> and colleagues don't define open(2) anymore;
> apparently, I have to use open64(2) instead.
No, you should still use plain "open".
It's defined in <fcntl.h>, as follows:
#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#ifdef __PRAGMA_REDEFINE_EXTNAME
#pragma redefine_extname open open64
#pragma redefine_extname creat creat64
#else
#define open open64
#define creat creat64
#endif
#endif /* !_LP64 && _FILE_OFFSET_BITS == 64 */
If you're using Sun C, __PRAGMA_REDEFINE_EXTNAME should be defined, so
you use the magic linker pragma; otherwise, you get a simple #define,
so your code can still use plain "open" but it actually uses open64.
For example, if your program looks like this:
#define _FILE_OFFSET_BITS 64
#include <fcntl.h>
int
main (void)
{
return open (".", O_RDONLY) < 0;
}
it should compile and run just fine, with either Sun C or GCC. In the
latter case, the return statement expands via the preprocessor to:
return open64 (".", 0) < 0;
so you don't need to have any instances of open64 in your code.
> how can I realiably determine, whether large-file support
> has been enabled or not?
Your code shouldn't need to care. It should just work.
In another mail you indicate you're using g++. I don't use g++
myself, but perhaps you can investigate why it's misbehaving.
Does gcc work on the above code for you? Does g++? If gcc does
not work, something is wrong with your installation, as it works
for me. If gcc works but g++ does not, you need to investigate why.