Have g++ define _FILE_OFFSET_BITS=64 on Solaris

[Franz Sirl]

Am 2018-06-22 um 09:51 schrieb Rainer Orth:
> Hi Franz,
> 
>> No idea about possible problems, but isn't it usually recommended to use
>> either _FILE_OFFSET_BITS=64 or _LARGEFILE{64}_SOURCE=1, not both at the
>> same time?
> 
> quite the contrary: for regular largefile support, you're supposed to
> use `getconf LFS_CFLAGS', i.e. -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64, while `getconf LFS64_CFLAGS'
> (-D_LARGEFILE64_SOURCE) enables the transitional largefile interfaces
> (e.g. explicit stat64 calls and struct stat64 instead of making stat and
> struct stat largefile-aware).
> 
> For all the gory details, see the lfcompile(7), lfcompile64(7), and
> lf64(7) man pages:
> 
> 	https://docs.oracle.com/cd/E88353_01/html/E37853/index.html
> 
> 	Rainer
> 

Hi Rainer,

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 doesn't explain -D_LARGEFILE64_SOURCE, does 
libstdc++ really need to use _LARGEFILE64_SOURCE functions?

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?
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.

Franz