[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: Have g++ define _FILE_OFFSET_BITS=64 on Solaris
From:       Franz Sirl <Franz.Sirl-kernel () lauterbach ! com>
Date:       2018-06-25 16:15:51
Message-ID: 442f382c-f1ab-b7ca-4088-dff1ad211b5a () lauterbach ! com
[Download RAW message or body]

Am 2018-06-25 um 15:57 schrieb Rainer Orth:
> Hi Franz,
> 
>> so you are supposed to use "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64",
>> but at least a quick glance at the Sol10 headers shows that the additional
>> -D_LARGEFILE_SOURCE only makes a difference for fseeko/ftello. That still
> 
> right, that's also explained in lfcompile(7).
> 
>> doesn't explain -D_LARGEFILE64_SOURCE, does libstdc++ really need to use
>> _LARGEFILE64_SOURCE functions?
> 
> Honestly, I hadn't checked, but wondered the same thing.  However, I'm a
> bit wary to simply remove them after years for fear of breaking user
> existing user code.

But adding _FILE_OFFSET_BITS=64 is the far bigger change for the user. 
Now suddenly (for 32-bit applications) off_t changes size and thus many 
applications with mixed C/C++-code simply might break. The reason is 
that now (if they didn't take care of _LARGEFILE_SOURCE themselves), for 
example fread() really does a fread64() in the C++ parts and a fread() 
(the 32-bit version) in the C parts. This situation was avoided before 
by enabling _LARGEFILE_SOURCE without _FILE_OFFSET_BITS=64.

>> Re-reading lfcompile(7) again shows that you can use either
>> "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" (for portable applications) or
>> only "-D_FILE_OFFSET_BITS=64". But in the GCC case we only need it for
>> C++/libstdc++ so it seems "-D_FILE_OFFSET_BITS=64" should be enough. The
>> rest is up to the users application, or?
> 
> One might argue that way, but again it's a bit late to change this now
> for no compelling reason.

The compelling reason is that with _FILE_OFFSET_BITS=64 all bets are off 
anyway IMO, see above.

>> My guess is that without defining _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE
>> the configure check in libstdc++-v3/acinclude.m4 just won't define
>> _GLIBCXX_USE_LFS and everything will fall in place. This would leave HPUX
>> as the last user of _GLIBCXX_USE_LFS.
> 
> I don't know about HP-UX, but _GLIBC_USE_LFS is defined on Linux/x86_64,
> too.  To me, the meaning seems a bit confused: 27_io/fpos/14775.cc
> suggests that it denotes all system with largefile support, while
> acinclude.m4 (GLIBCXX_CHECK_LFS) only tests for the transitional
> functions (enabled by _LARGEFILE64_SOURCE on Solaris) while ignoring the
> `transparent' largefile support from _LARGEFILE_SOURCE
> _FILE_OFFSET_BITS=64.
> 
> I'd rather not mess with this stuff.

That I can fully understand ;-). Maybe a solution is to define the 
macros also for C, not only for C++. And to conditionalize 
_LARGEFILE_SOURCE on 32-bit compile and _LARGEFILE64_SOURCE on 64-bit 
compile to make it at least less confusing.

Franz
[prev in list] [next in list] [prev in thread] [next in thread]