Re: [lmi] Why does wx define _FILE_OFFSET_BITS ?

[Vadim Zeitlin]

On Sun, 24 Mar 2019 20:55:29 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-03-20 11:28, Greg Chicares wrote:
GC> > On 2019-03-19 23:50, Vadim Zeitlin wrote:
GC> >> On Tue, 19 Mar 2019 19:41:37 +0000 Greg Chicares <address@hidden> wrote:
GC> >> 
GC> >> GC> Debian "buster" now has MinGW-w64 gcc-8.2,
GC> [...]
GC> >> GC> wxWidgets rebuilt with no warnings at all except this:
GC> >> GC> 
GC> >> GC> i686-w64-mingw32-gcc -c -o wxtiff_tif_predict.o -DNDEBUG 
-I/cache_for_lmi/vcs/wxWidgets/src/zlib -I/cache_for_lmi/vcs/wxWidgets/src/jpeg 
-I/opt/lmi/wx-scratch/lmi-gcc-8.2-win32/src/tiff/libtiff 
-I/cache_for_lmi/vcs/wxWidgets/src/tiff/libtiff  -D_FILE_OFFSET_BITS=64 [...]
GC> 
GC> _FILE_OFFSET_BITS is defined when building wx (with autotools)...
[...]
GC> Since it's defined by wx, I'm surprised that it has no "WX" prefix.

 This is because it's a glibc macro, not a wx one, see e.g.

https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html

At least under Linux, the code using wxWidgets needs to be compiled with
the same value of this macro as wxWidgets itself, because wxFileOffset,
used in wx public headers, is just off_t, and has to be of the same size
inside and outside of the library. And wxWidgets enables large file support
by default (which definitely makes sense) and unconditionally (which might
be a bit too opinionated, but nobody has complained about it during the ~20
years it was there).

GC> My conjecture is that
GC>  - wx internals depend on the legacy API having been replaced by
GC>    the 64-bit API;
GC>  - that replacement must be done at the OS level, and defining
GC>    this macro is the normal way of effecting the replacement;
GC>  - even if the macro originated in *nix, it's been adopted into msw
GC> and so in this case it's proper for wx to define it, and to do so
GC> via 'wx-config' so that it's defined before any header is read.
GC> Right?

 I don't know if this macro is used with MinGW, but either it is, in which
case it should still be defined, or it isn't, in which case defining it
should be harmless.

GC> This leads to a concern: what if I write a module that uses the
GC> affected functions in the C runtime library, and compile it without
GC> the 'wx-config' CXXFLAGS? To remove that concern, I suppose lmi's
GC> makefiles should themselves define '-D_FILE_OFFSET_BITS=64'. Right?

 If the code doesn't use wxFileOffset, it shouldn't matter whether it uses
32 or 64-bit off_t. But, of course, defining _FILE_OFFSET_BITS=64 is needed
(again, at least under Linux and some other Unix systems, I don't know if
it's also the case under MSW) if you want to work with large files, so it
might be a good idea to define it anyhow, just in case human life
expectancy increases so much that the various tables used in lmi don't fit
into just 2GiB any longer (don't tell me I'm not an optimist, I can always
imagine new and exciting ways for things to break).

 Regards,
VZ