> -----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.
If it doesn't, mea culpa.
I can see if there is a patch or a PKGBUILD function that modifies the specs
file
and give that a whirl.
Tom
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
