With your latest two patches, the toolchain compiles but I get an error when building a shared library:
/nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_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-w64-crt/crt/gccmain.c:25: undefined reference to `__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-w64-crt/crt/gccmain.c:25: undefined reference to `__DTOR_END__' /nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-gccmain.o):gccmain.c:(.data+0x0): undefined reference to `__CTOR_END__' Maybe crtexe.c is not linked into shared libraries since they are not EXEs. --David On Fri, Aug 4, 2017 at 6:12 PM, David Grayson <davidegray...@gmail.com> wrote: > Oh, I mean that I got the patch to apply, but I don't know if it > really *works*; the toolchain is still building at this time. --David > > On Fri, Aug 4, 2017 at 6:11 PM, David Grayson <davidegray...@gmail.com> wrote: >> Your binutils patch did not apply cleanly to binutils-2.27 but I got >> it to work. It looks pretty dangerous to me because you removed the >> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And >> you're using .ctors and .dtors in your other patch, and other code >> might use them too I suppose. >> >> --David >> >> On Fri, Aug 4, 2017 at 5:39 PM, Martell Malone <martellmal...@gmail.com> >> wrote: >>> Hey David, >>> >>> This could be caused by gcc including it's own crtbegin.o and crtend.o >>> I managed to install a toolchain with brew and I swapped out gcc's and >>> mingw-w64's crtbegin and crtend. >>> Everything seems to work here as intended. >>> Attached is an updated patch that avoids crtbegin and crtend that should >>> work along with a patch for binutils. >>> >>> Kai could you give some input on the binutils patch. >>> On a side note while we are at this we should change __image_base__ >>> to ___ImageBase and __ImageBase on x86 and x64 respectively. >>> Best, >>> Martell >>> >>> On Sat, Aug 5, 2017 at 12:20 AM, David Grayson <davidegray...@gmail.com> >>> wrote: >>> >>>> 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/b >>>> uild_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/b >>>> uild_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/b >>>> uild_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/b >>>> uild_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/b >>>> uild_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/b >>>> uild_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 <martellmal...@gmail.com> >>>> 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ö <mar...@martin.st> wrote: >>>> > >>>> >> On Fri, 4 Aug 2017, Ruben Van Boxem wrote: >>>> >> >>>> >> Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" < >>>> martellmal...@gmail.com >>>> >>> >: >>>> >>> >>>> >>> 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 >>>> >> Mingw-w64-public@lists.sourceforge.net >>>> >> 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 >>>> > Mingw-w64-public@lists.sourceforge.net >>>> > 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 >>>> Mingw-w64-public@lists.sourceforge.net >>>> 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 >>> Mingw-w64-public@lists.sourceforge.net >>> 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
