On Wed, 24 Apr 2019, Kacvinsky, Tom wrote:
Hi Martin,
-----Original Message-----
From: Martin Storsjö <[email protected]>
Sent: Wednesday, April 24, 2019 7:55 AM
To: [email protected]
Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having
GCC compile errors
On Wed, 24 Apr 2019, Martin Storsjö wrote:
I tried bootstrapping a new separate install of gcc into a new sysroot
all within msys, in the same way as I bootstrap cross toolchains on
linux. It almost works, except for building some of the ADA tools. I
tried just copying in gnatmake/gnatbind/gnatlink from the existing
msys environment though, and that works, even if it is very ugly...
You can have a look at the full toolchain at
https://martin.st/temp/mingw-native.zip. My instructions/notes for how
I tried to build it are attached, and also available at
https://martin.st/temp/gcc-ucrt.txt in case the mailing list eats the
attachment. I haven't rerun/rechecked the instructions properly yet,
but they're just notes from what I'm trying to run while building this.
The gist of it is: Build new binutils and the host part of gcc into a
new sysroot. Install the mingw crt into the same sysroot. Build the
runtime parts of gcc using that same crt and install into the sysroot. Done.
All of this works splendidly, except for the ada parts, which I'm
woefully unfamiliar with.
With this toolchain, I'm able to do "gnatmake hello.adb", which
produces a hello.exe that links against the UCRT DLLs.
But like I said, the bin/gnatmake.exe, bin/gnatlink.exe and
bin/gnatbind.exe are just hacked around from my msys2 executables so far.
I tweaked the build a bit more and experimented further, and have
reproduced it a bit more. Now I'm able to build the ada tools as well.
The kind of single-stage non-bootstrap build I do requires having the same
version of gcc in the existing environment as I'm building though.
I've rebuilt a new toolchain available at https://martin.st/temp/gcc-8.3-ada-
ucrt.zip, and new updated instructions at https://martin.st/temp/gcc-ucrt.txt
(also attached for archival). The new one is built with gcc 8.3 (even though
the instructions mention 7.3).
I followed the latest instructions and the initial build went smoothly, though
gnatdll
was not built. I fixed that up with a separate, manual, "make gnattools". Now
I can
produce the hello world example and make a DLL via gnatdll.
One last question - I still see msvcrt.dll in ldd output of my executable and
DLL. I
even tried making a new specs file with -lmsvcrt replaced my -lucrt, but that
DLL
still shows up in the ldd output.
I suppose I am missing something here - is this or is this not expected
behavior? We
would like to not have msvcrt.dll in the mix as this has proven to cause lots
and lots
of pain in the past (allocated in one DLL, free in another, for instance).
At least for a plain hello world project, msvcrt.dll is not loaded by the
built executable itself. (You can check with objdump -x foo.exe; a bit
down you find the import tables.)
In my case, I also do see msvcrt.dll though. If looking through the
dependencies with e.g. Dependency Walker, I see that some of the linked
DLls, advapi32.dll and shell32.dll do load msvcrt.dll. While this does
seem a bit weird, apparently it's unavoidable as long as the system DLLs
link against it. And it shouldn't hurt, because a DLL loaded on windows
can't affect other ones in the same process (contrary to how shared
objects with one global symbol namespace works on ELF).
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
