From: David Judson (djudson_at_[hidden])
Date: 2004-05-10 08:54:25
At 04:40 PM 5/8/2004, you wrote:
>At 06:31 AM 5/8/2004, you wrote:
> >> This caught my eye since I have code that depends on Large File Support
> >> (LFS). Though, for reasons alluded to below, I get LFS via C stdio
> >> instead of C++ streams.
> >> For the record, the LFS standard is here:
> >> http://ftp.sas.com/standards/large.file/
> >> I wonder if there would be complications if LFS were enabled in Boost by
> >> default?
> >I think it is for Boost.Filesystem now - see
>Yes, that's correct. The macro __USE_FILE_OFFSET64 is always defined when
>BOOST_POSIX is defined. So users of current CVS code don't have to do
>anything special to get 64-bit support.
>Note that the LFS standard document above seems to be out-of-date as far
>as the macro name is concerned. The name was determined on Linux by
>inspecting the actual header file, and verified by testing. If anyone runs
>into a system which uses a different macro name, please let us know.
I believe that the macro __USE_FILE_OFFSET64 is an internal GNU macro and
should not be defined in user code. If you examine the header file
"features.h" you will see that this macro is undefined and then possibly
redefined based on the value of various standard macros. The LFS standard
says that to enable "large" off_t, use the compiler option returned by
"getconf LFS_CFLAGS" which on Linux returns -D_FILE_OFFSET_BITS=64. In
"features.h", this macro will eventually cause __USE_FILE_OFFSET64 to be
defined. The only way that __USE_FILE_OFFSET64 would work is if you set it
after including the system header files and it won't work on non-GNU systems.
The standard way to do enable 64 bit offsets is set the value returned by
"getconf LFS_CFLAGS" . This should be done in the jam build script. This
works on Linux, Solaris and Irix. I don't have access to a recent AIX
system (5.x) to test.
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk