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.
> 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.
> 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.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
