On Mon, 22 Apr 2019, Kacvinsky, Tom wrote:
-----Original Message-----
From: Kacvinsky, Tom <[email protected]>
Sent: Monday, April 22, 2019 9:26 AM
To: [email protected]
Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having
GCC compile errors
<snip/>
OK, I can give this a whirl. the main problem I face is not so much GCC's C and
C++ compilers building as it is the GNAT compiler building. When you go to
build that, it wants to pull in the systems libgnat.a, which contains the symbol
_p_environ, which is not resolved:
ada/argv.o:argv.c:(.text+0x9a): undefined reference to
`__imp___p__environ'
ada/argv.o:argv.c:(.text+0xc9): undefined reference to
`__imp___p__environ'
ada/argv.o:argv.c:(.text+0x10b): undefined reference to
`__imp___p__environ'
ada/env.o:env.c:(.text+0x96): undefined reference to
`__imp___p__environ'
ada/env.o:env.c:(.text+0x10a): undefined reference to
`__imp___p__environ'
collect2.exe: error: ld returned 1 exit status
I know _p_environ is part of the UCRT, if I recall correctly, so why building
the
CRT with UCRT support and installing ended up with an unresolved symbol, I
don't know.
Any help with this particular facet would be greatly appreciated. I am oh so
close to getting this nailed own.
I got sneaky and tried the failed link command by hand, but passing a specs
file (via -specs) in which I had changed -lmsvcrt to -lucrt. That fixed up the
link error. But this now raise the question - if I built mingw-crt-git with
-with-default-msvcrt=ucrt
Not only should it change the compiler define for the MSVC version, shouldn't
it change libmsvcrt.a to load the UCRT DLLs at runtime? If it is supposed to,
it
appears it isn't based on my last build of it.
Yes, it should have. Technically; mingw-w64-crt installs many different
lib*crt*.a; the one that links to msvcrt.dll is named libmsvcrt-os.a and
the ucrt ones are libucrtbase.a and libucrt.a. (The latter is the one you
probably want to use.) The --with-default-msvcrt option changes which one
of them is copied to be named libmsvcrt.a, which is the one that is linked
in implicitly.
So it sounds to me like this linking step is linking using the wrong (old)
mingw installation directory, not the new one (where libmsvcrt.a is a copy
of libucrt.a).
I'm not sure exactly where in the build process you're running into this;
while building the runtime libraries at the end of the build of your new
gcc, or while trying to actually build code using it (and I don't know how
ada building is supposed to work and how it interacts with linking and C
haders).
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public