Hey David,

> 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.


It applies cleanly to HEAD.
I changed to so that all it does is SORT the ctors and dtors sections.
Someone would have to confirm though.

Maybe crtexe.c is not linked into shared libraries since they are not EXEs.

 That is exactly what happened there crtdll.c is used instead.
Here is an updated patch which also applies to crtdll.c

Also the only reason I am not putting it into gccmain.c is because I am
having problems with creating it and then using is as a array.
If someone is able to do that it would be much better.

Transforming
__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void
*)))) const func_ptr __CTOR_LIST__[] = {(void *) -1};
into
func_ptr __CTOR_LIST__[]
is being problematic within the one source.

I'd gladly take direction from someone here on that if they have any ideas.

Best,
Martell

On Sat, Aug 5, 2017 at 5:53 AM, David Grayson <davidegray...@gmail.com>
wrote:

> 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/s27xhxkbq4qxadhzpn5vh5kkffnfvi
> zy-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/s27xhxkbq4qxadhzpn5vh5kkffnfvi
> zy-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
>
From 7241aa2c5f272ac0df4240c8df8d970bcfdc45ef Mon Sep 17 00:00:00 2001
From: Martell Malone <martellmal...@gmail.com>
Date: Fri, 5 Aug 2016 20:09:41 -0700
Subject: [PATCH] Handle __CTOR_LIST__ within mingw-w64


diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 07a18408..f8541256 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -40,6 +40,11 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
 extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
 extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
 
+__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *)))) 
const void * __CTOR_LIST__ = (void *) -1;
+__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *)))) 
const void * __DTOR_LIST__ = (void *) -1;
+__attribute__ (( __section__ (".ctors$zzz"), __used__ , aligned(sizeof(void 
*)))) const void * __CTOR_END__ = (void *) 0;
+__attribute__ (( __section__ (".dtors$zzz"), __used__ , aligned(sizeof(void 
*)))) const void * __DTOR_END__ = (void *) 0;
+
 /* TLS initialization hook.  */
 extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback;
 
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index ae37e0fe..4e8cda5a 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -60,6 +60,11 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
 extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
 extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
 
+__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *)))) 
const void * __CTOR_LIST__ = (void *) -1;
+__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *)))) 
const void * __DTOR_LIST__ = (void *) -1;
+__attribute__ (( __section__ (".ctors$zzz"), __used__ , aligned(sizeof(void 
*)))) const void * __CTOR_END__ = (void *) 0;
+__attribute__ (( __section__ (".dtors$zzz"), __used__ , aligned(sizeof(void 
*)))) const void * __DTOR_END__ = (void *) 0;
+
 /* TLS initialization hook.  */
 extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback;
 
diff --git a/mingw-w64-crt/crt/gccmain.c b/mingw-w64-crt/crt/gccmain.c
index fc0e3500..4363fd6a 100644
--- a/mingw-w64-crt/crt/gccmain.c
+++ b/mingw-w64-crt/crt/gccmain.c
@@ -11,6 +11,8 @@
 typedef void (*func_ptr) (void);
 extern func_ptr __CTOR_LIST__[];
 extern func_ptr __DTOR_LIST__[];
+extern func_ptr __CTOR_END__[];
+extern func_ptr __DTOR_END__[];
 
 void __do_global_dtors (void);
 void __do_global_ctors (void);
@@ -20,30 +22,20 @@ void
 __do_global_dtors (void)
 {
   static func_ptr *p = __DTOR_LIST__ + 1;
-
-  while (*p)
-    {
-      (*(p)) ();
+  while(p < __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] ();
-    }
-
+  static func_ptr *p = __CTOR_END__ - 1;
+  while(p > __CTOR_LIST__) {
+    if (*p) (*(p)) ();
+      p--;
+  }
   atexit (__do_global_dtors);
 }
 
-- 
2.13.4

------------------------------------------------------------------------------
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

Reply via email to