[lmi] Why does wx define _FILE_OFFSET_BITS ? [Was: Warnings with gcc-8.2]

[Greg Chicares]

On 2019-03-20 11:28, Greg Chicares wrote:
> On 2019-03-19 23:50, Vadim Zeitlin wrote:
>> On Tue, 19 Mar 2019 19:41:37 +0000 Greg Chicares <address@hidden> wrote:
>> 
>> GC> Debian "buster" now has MinGW-w64 gcc-8.2,
[...]
>> GC> wxWidgets rebuilt with no warnings at all except this:
>> 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 [...]

_FILE_OFFSET_BITS is defined when building wx (with autotools)...

> Here's the entire command for compiling 'previewframe_ex.o', with all
> of its output:
> 
> i686-w64-mingw32-g++ -MMD -MP -MT previewframe_ex.o -MF previewframe_ex.d  -c 
> -I /opt/lmi/src/lmi -I /opt/lmi/src/lmi/tools/pete-2.1.1 -I 
> /opt/lmi/local/lib/wx/include/i686-w64-mingw32-msw-unicode-3.1 -I 
> /opt/lmi/local/include/wx-3.1 -I /opt/lmi/third_party/include -I 
> /opt/lmi/third_party/src -I /opt/lmi/local/include -I 
> /opt/lmi/local/include/libxml2 -DLMI_WX_NEW_USE_SO  -DLIBXML_USE_DLL -DSTRICT 
>    -D_FILE_OFFSET_BITS=64 [...]
...and also when building lmi (with its own makefiles). But that
appears to be a glibc macro, and I wondered where it got defined.

These commands return nothing:

i686-w64-mingw32-g++ -dM -E - < /dev/null | grep _FILE_OFFSET_BITS
x86_64-w64-mingw32-g++ -dM -E - < /dev/null | grep _FILE_OFFSET_BITS

and neither does this:
/opt/lmi/src/lmi[0]$git log -G'_FILE_OFFSET_BITS'

but...aha...

wx-config --cxxflags |grep _FILE_OFFSET_BITS
-I/opt/lmi/local/lib/wx/include/i686-w64-mingw32-msw-unicode-3.1 
-I/opt/lmi/local/include/wx-3.1 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ 
-mthreads

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

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