search

psmedley / gcc

GNU General Public License v2.0
7 stars 1 forks source link

Build gccXXX.dll from gcc config or from libgcc config #4

Open dmik opened 10 years ago

dmik commented 10 years ago

In GCC 4.4.6 (and in all earlier versions of 4.x.x) the gcc4XX.dll file was built using the makefile from gcc/config/i386/t-emx.

In GCC 4.7.3 it is built using the makefile from libgcc/config/i386/t-emx.

These make files are slightly different. The one in libgcc seems to be made after the gcc/config/i386/t-emx file from the GCC 3 builds by Knut (a copy of this file is also here: http://trac.netlabs.org/libc/browser/branches/libc-0.6/src/gcc/gcc/config/i386/t-emx).

The one in gcc looks like a derivative of both of both or so (???).

This looks completely wrong to me, there should be only one source for gccXXX.dll.

dmik commented 10 years ago

It looks like updating our GCC 4.4.6 to 4.7.3 (done by @psmedley) changed the source for gccXXX.dll. This caused problems (the file descriptors of open files were not properly flushed at exit) because the makefile in libgcc uses the INITINSTANCE TERMGLOBAL flag for the DLL which caused _DLL_InitTerm to be called in each process at startup but only in the last process at termination. Also, the _DLL_InitTerm routine lacks a call to _CRT_Term upon termination.

dmik commented 10 years ago

There was a similar problem in gcc3xx.dll supplied with the kLIBC builds from Knut. He applied a patch from @ydario fixing it here: http://trac.netlabs.org/libc/changeset/3855 (0.6 branch) and here: http://trac.netlabs.org/libc/changeset/3856 (0.7 branch).

While the TERMGLOBAL fix is pretty much obvious, I apply neither of them here because I really want us to clear out the main question of this issue first.

In particular, it's not clear why we should use a custom _DLL_InitTerm in gcc.dll in the first place — the default one provided when you build a DLL with gcc -Zdll does just exactly what we need, see here: http://trac.netlabs.org/libc/browser/branches/libc-0.6/src/emx/src/lib/startup/dllinit.c.

Then, we should sort out the differences between the gcc and the libgcc build of gcc.dll and merge them into one file.

ydario commented 9 years ago

From what I saw, in 3.x era all configuration files were in gcc/config dir only. Then later gcc guys moved runtime files to a new place, libgcc dir. I think that when Paul updated the tree, he copied files from old location to new one.

But gcc/config stuffs are still needed, if I delete them it is not possible to build xgcc. This means some work is needed to trim gcc/config/t-emx to a minimal size (probably only inference rules at end).