Re: Have g++ define _FILE_OFFSET_BITS=64 on Solaris

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

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