Martell: My setup ( https://github.com/DavidEGrayson/nixcrpkgs ) makes it quite easy to try random patches and make sure that GCC can still be bootstrapped and that I can build non-trivial applications. I tried your patch (after fixing the linebreaks added by GMail) but unfortunately it doesn't work.
When building the final GCC, I got this error: ~~~~ checking for ld that supports -Wl,--gc-sections... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [Makefile:9917: configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory '/tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build' make: *** [Makefile:878: all] Error 2 ~~~~ I've experienced this before and it just means something went wrong earlier in the configure script, and GCC, in its infinite wisdom, decided that it was targeting a system that does not support executables (?). Digging through the config.log for libstdc++-v3, I found a suspicious error: ~~~~ configure:3952: $? = 1 configure:3968: /tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build/./gcc/xgcc -B/tmp/nix-build-gcc-6.3.0-i686-w64-m ingw32.drv-0/build/./gcc/ -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/li b -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/mingw/lib -isystem /nix/store/s27xhxkbq4qxa dhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/include -isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkff nfvizy-gcc-6.3.0-i686-w64-mingw32/mingw/include -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw 32/i686-w64-mingw32/bin/ -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/lib / -isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/include -isystem /n ix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/sys-include -o conftest -g -O 2 conftest.c >&5 /nix/store/262jyalfa9jz5say3782fcdh2zw4n301-mingw-w64-2017-08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmin gw32_a-gccmain.o): In function `_do_global_dtors': /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_LIST__' /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__' /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__' /nix/store/262jyalfa9jz5say3782fcdh2zw4n301-mingw-w64-2017-08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmin gw32_a-gccmain.o): In function `_do_global_ctors': /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w 64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_END__' /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w 64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_LIST__' /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w 64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_LIST__' ~~~~ I'm not sure why those things would be undefined, but the order of linking of these libraries does matter and perhaps they are being linked in the wrong order. --David On Fri, Aug 4, 2017 at 12:50 PM, Martell Malone <[email protected]> wrote: > Okay lets just solve this. > I believe the following should work for both clang and gcc > I added a test case at the bottom also. > > diff --git a/mingw-w64-crt/crt/crtbegin.c b/mingw-w64-crt/crt/crtbegin.c > index 39c0d856..1672f7b9 100644 > --- a/mingw-w64-crt/crt/crtbegin.c > +++ b/mingw-w64-crt/crt/crtbegin.c > @@ -4,3 +4,5 @@ > * No warranty is given; refer to the file DISCLAIMER.PD within this > package. > */ > > +__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void > *)))) const void * __MINGW_CTOR_LIST__ = (void *) -1; > +__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void > *)))) const void * __MINGW_DTOR_LIST__ = (void *) -1; > diff --git a/mingw-w64-crt/crt/crtend.c b/mingw-w64-crt/crt/crtend.c > index 39c0d856..d1b6b426 100644 > --- a/mingw-w64-crt/crt/crtend.c > +++ b/mingw-w64-crt/crt/crtend.c > @@ -4,3 +4,5 @@ > * No warranty is given; refer to the file DISCLAIMER.PD within this > package. > */ > > +__attribute__ (( __section__ (".ctors$zzz"), __used__ , > aligned(sizeof(void *)))) const void * __MINGW_CTOR_END__ = (void *) 0; > +__attribute__ (( __section__ (".dtors$zzz"), __used__ , > aligned(sizeof(void *)))) const void * __MINGW_DTOR_END__ = (void *) 0; > diff --git a/mingw-w64-crt/crt/gccmain.c b/mingw-w64-crt/crt/gccmain.c > index fc0e3500..7401e812 100644 > --- a/mingw-w64-crt/crt/gccmain.c > +++ b/mingw-w64-crt/crt/gccmain.c > @@ -9,8 +9,10 @@ > #include <setjmp.h> > > typedef void (*func_ptr) (void); > -extern func_ptr __CTOR_LIST__[]; > -extern func_ptr __DTOR_LIST__[]; > +extern func_ptr __MINGW_CTOR_LIST__[]; > +extern func_ptr __MINGW_DTOR_LIST__[]; > +extern func_ptr __MINGW_CTOR_END__[]; > +extern func_ptr __MINGW_DTOR_END__[]; > > void __do_global_dtors (void); > void __do_global_ctors (void); > @@ -19,31 +21,21 @@ void __main (void); > void > __do_global_dtors (void) > { > - static func_ptr *p = __DTOR_LIST__ + 1; > - > - while (*p) > - { > - (*(p)) (); > + func_ptr *p = __MINGW_DTOR_LIST__ + 1; > + while(p < __MINGW_DTOR_END__) { > + if (*p) (*(p)) (); > p++; > - } > + } > } > > void > __do_global_ctors (void) > { > - unsigned long nptrs = (unsigned long) (ptrdiff_t) __CTOR_LIST__[0]; > - unsigned long i; > - > - if (nptrs == (unsigned long) -1) > - { > - for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++); > - } > - > - for (i = nptrs; i >= 1; i--) > - { > - __CTOR_LIST__[i] (); > - } > - > + func_ptr *p = __MINGW_CTOR_END__ - 1; > + while(p > __MINGW_CTOR_LIST__) { > + if (*p) (*(p)) (); > + p--; > + } > atexit (__do_global_dtors); > } > > Attached also is a testcase for ctors and dtors > > #include <stdio.h> > > void ctorTest(void) __attribute__ ((constructor)); > void dtorTest(void) __attribute__ ((destructor)); > > void ctorTest(void) { > printf ("ctor before main\n"); > } > > void dtorTest(void) { > printf ("dtor after main\n"); > } > > int main() > { > printf ("hello\n"); > return 0; > } > > I get the following output with clang. > > ctor before main > hello > dtor after main > > Can someone test this on a gcc toolchain and confirm. > I haven't built a mingw-w64 with gcc and binutils in so long. > > Best, > Martell > > On Fri, Aug 4, 2017 at 7:53 PM, Martin Storsjö <[email protected]> wrote: > >> On Fri, 4 Aug 2017, Ruben Van Boxem wrote: >> >> Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" <[email protected] >>> >: >>> >>> I for one would like to be able to use one crt with both Clang and GCC. No >>> use in duplicating 99% of the code for that one little bit of startup code >>> that needs to be different. Perhaps ldd or Clang needs to be taught to >>> link >>> a different startup object, but that should be trivial to accomplish! >>> >> >> Being able to use the same build of mingw with either compiler (or more >> practically, linker) would be ideal yeah. In addition to the constructor >> handling, there's also the issue that lld fails to link to import libraries >> created by GNU dlltool. >> >> >> Initial brain dump of what I've discovered on the matter so far: >> >> MSVC link.exe also used to fail linking to such import libraries (with >> slightly different symptoms), prior to MSVC 2012 where it started working. >> (Not sure if this was an intentional fix from their side or not.) >> >> With link.exe, the output binary does link to the DLL, but doesn't >> actually import the functions. With lld, the output binary doesn't actually >> end up linking to the DLL at all, iirc. >> >> In lld, in LinkerDriver::addArchiveBuffer, the "proper" import libraries >> (from the windows SDK, and the ones produced by llvm-dlltool) get >> identified as coff_import_library and get treated differently, while the >> GNU dlltool ones just are treated as any normal static library-. >> >> >> // Martin >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Mingw-w64-public mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
