>
> I think Martell's last patch would have worked but it's not as safe as
> I would like it to be. I think the constructor and destructor lists
should not be defined in gccmain.c where they are used, because then
> the compiler optimizer might start to get smart and stop optimizing
> things in a bad way.
That won't happen, this is what the attribute __used__ is for.
The issue I have is about casting in a clean way.
I also don't see the point in iterating through a list to get to the end
and then navigating back through it again if you have a pointer to the last
element.
>
> Also, I think we should add new symbols so there is no potential for a
> clash with the symbols defined by the linker script in binutils.
As I said in a previous email this would be one way to solve it yes.
Here is what I said
> This would mean that programs linked with LD would have an extra 2
pointers in the table but it should be fine otherwise.
I would be cleaner and better to change the linker script though.
On Sat, Aug 5, 2017 at 6:15 PM, David Grayson <davidegray...@gmail.com>
wrote:
> Oops, here is the patch.
>
> On Sat, Aug 5, 2017 at 10:14 AM, David Grayson <davidegray...@gmail.com>
> wrote:
> > I think Martell's last patch would have worked but it's not as safe as
> > I would like it to be. I think the constructor and destructor lists
> > should not be defined in gccmain.c where they are used, because then
> > the compiler optimizer might start to get smart and stop optimizing
> > things in a bad way. The kind of pointer arithmetic we're doing would
> > be undefined behavior since we're intentionally getting a pointer to
> > an object and then reading past the end of that object.
> >
> > Also, I think we should add new symbols so there is no potential for a
> > clash with the symbols defined by the linker script in binutils.
> >
> > So, attached to this email is a patch that worked for me (I was able
> > to compile and run a Qt Widgets application). I'm not entirely sure
> > it would be a good patch to use though, since I'm not sure how GCC
> > picks names for its global constructor and destructor sections, and
> > how it sorts those names, so I'm not sure that the symbols we are
> > defining would really be in the right place.
> >
> > --David Grayson
> >
> > On Sat, Aug 5, 2017 at 4:45 AM, Martell Malone <martellmal...@gmail.com>
> wrote:
> >> 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
> >>>
> >>
> >> ------------------------------------------------------------
> ------------------
> >> 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
