On Tue, 26 Mar 2019, Kacvinsky, Tom wrote:
I understand the data symbol _environ should not be used as outlined in
MSDN documentation. That said, libgnat.a from MinGW-w64 6.0.0 (as
installed via pacman in MSYS2) still uses it
I suitably modified ucrtbase.def to add
_environ DATA
rebuilt the import libraries and all is well. So I am wondering if these
deprecated symbols should be added to ucrtbase.def,
It's not missing because it's deprecated or something of that effect. It's
missing because ucrtbase.dll doesn't export any symbol named _environ.
If you build code that reference the _environ variable with headers set to
__MSVCRT_VERSION__ >= 0x1400, "_environ" will expand to (*
__p__environ()).
Code that already is built, that expects _environ to be a data symbol
imported from a dll, won't work easily, unless we add more compat wrapping
to simulate the variable. (We do this for a select number of symbols, to
make libmingw32.a and libmingwex.a work. Have a look at
mingw-w64-crt/ucrtbase_compat.c for an insight into what's done there.)
or if libgnat.a should be rebuilt to not use the deprecated functions.
I think the latter is the right thing to do, but until that can be
accomplished, the low hanging fruit is to update the export definition
files.
This is one clear case why code that will link against libucrt*.a should
be built with the right headers. You can try to spend the extra effort to
extend ucrtbase_compat.c to handle this variable as well if rebuilding
isn't an option for you, but at some point you really do want to look into
rebuilding it.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
