Microsoft just published an article about this kind of thing: https://blogs.msdn.microsoft.com/oldnewthing/20170927-00/?p=97095
It seems that casting pointers to uintptr_t before comparing them would probably be safe. --David Grayson On Sat, Aug 5, 2017 at 12:44 PM, David Grayson <[email protected]> wrote: > What I meant is that if GCC's optimizer ever figures out that we are > comparing pointers that came from two different memory objects, it > would know we are doing undefined behavior and would have a license to > do whatever it wants, including removing that code. The way the loop > is written right now is probably safer than anything that uses a > symbol at the end of the constructors. > > --David > > On Sat, Aug 5, 2017 at 11:52 AM, Martell Malone <[email protected]> > 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. >> >> 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 <[email protected]> >> wrote: >> >>> Oops, here is the patch. >>> >>> On Sat, Aug 5, 2017 at 10:14 AM, David Grayson <[email protected]> >>> 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 <[email protected]> >>> 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 <[email protected]> >>> >> 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 <[email protected] >>> > >>> >>> 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 < >>> [email protected]> >>> >>> 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 < >>> [email protected]> >>> >>> 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 < >>> >>> [email protected]> >>> >>> >>> 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 < >>> >>> [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 >>> >>> >>>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------ >>> >>> ------------------ >>> >>> >>> 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 >>> >> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> 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
