Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
Erik van Pienbroek schreef op do 23-05-2013 om 23:29 [+0200]: Hi, During review of one of our Fedora packages we noticed an unexpected change in behavior in recent mingw-w64 trunk snapshots. We noticed that several libraries which were built against recent mingw-w64 trunk snapshots suddenly started to export the symbols _InterlockedCompareExchange and InterlockedCompareExchange@12 in their shared libraries. Just a heads up that this regression is resolved now in mingw-w64 trunk. This is probably due to r5949 which was committed today (which changes the way the Interlocked symbols are implemented in mingw-w4). In Fedora we've dropped our local patch which was used to temporary workaround the issue. Regards, Erik van Pienbroek Fedora MinGW SIG -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
On 06/16/13 11:42, Erik van Pienbroek wrote: Erik van Pienbroek schreef op vr 14-06-2013 om 19:28 [+0200]: For now I've managed to workaround the regression by partially reverting r5713. This change makes intrincs/ilockcxch.c part of libmingwex instead of libkernel32 (as it was before r5713). I'm using this patch now in the Fedora mingw-w64 toolchain where it will be used until a proper solution has come up. Unfortunately a similar issue has also started to show up on the x86_64 target. As of r5898 shared libraries (which are generated without an explicit .def file) start to export the symbol __mingw_get_msvcrt_handle as can be seen with this minimal testcase: $ touch foo.c $ cat foo.c $ x86_64-w64-mingw32-gcc -shared foo.c -o foo.dll $ x86_64-w64-mingw32-objdump -p foo.dll | grep -A2 '\[Ordinal/Name Pointer\] Table' [Ordinal/Name Pointer] Table [ 0] __mingw_get_msvcrt_handle In Fedora we've also reversed this specific commit (r5898) for now until a proper solution comes up. I committed a fix for that (r5912). Thanks for the report. Jacek -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
Erik van Pienbroek schreef op vr 14-06-2013 om 19:28 [+0200]: For now I've managed to workaround the regression by partially reverting r5713. This change makes intrincs/ilockcxch.c part of libmingwex instead of libkernel32 (as it was before r5713). I'm using this patch now in the Fedora mingw-w64 toolchain where it will be used until a proper solution has come up. Unfortunately a similar issue has also started to show up on the x86_64 target. As of r5898 shared libraries (which are generated without an explicit .def file) start to export the symbol __mingw_get_msvcrt_handle as can be seen with this minimal testcase: $ touch foo.c $ cat foo.c $ x86_64-w64-mingw32-gcc -shared foo.c -o foo.dll $ x86_64-w64-mingw32-objdump -p foo.dll | grep -A2 '\[Ordinal/Name Pointer\] Table' [Ordinal/Name Pointer] Table [ 0] __mingw_get_msvcrt_handle In Fedora we've also reversed this specific commit (r5898) for now until a proper solution comes up. Regards, Erik van Pienbroek -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
Kai Tietz schreef op ma 10-06-2013 om 21:49 [+0200]: 2013/6/10 Erik van Pienbroek e...@vanpienbroek.nl: Any news on this issue? I will take a look to this this evening. We will need to remove here the alias-code to fix that For now I've managed to workaround the regression by partially reverting r5713. This change makes intrincs/ilockcxch.c part of libmingwex instead of libkernel32 (as it was before r5713). I'm using this patch now in the Fedora mingw-w64 toolchain where it will be used until a proper solution has come up. Regards, Erik van Pienbroek --- mingw-w64-crt/Makefile.am.revert_r5713 2013-06-13 17:27:36.0 +0200 +++ mingw-w64-crt/Makefile.am 2013-06-14 17:46:50.774319773 +0200 @@ -154,7 +154,7 @@ secapi/wmemcpy_s.c -src_libmingwex=\ +src_libmingwex=intrincs/ilockcxch.c\ crt/dllentry.ccrt/dllmain.c \ \ complex/cabs.c complex/cabsf.ccomplex/cabsl.c complex/cacos.ccomplex/cacosf.c complex/cacosl.c \ @@ -258,7 +258,7 @@ intrincs/__stosw.cintrincs/_rotl64.cintrincs/_rotr64.c intrincs/bitscanfwd.cintrincs/bitscanrev.c \ intrincs/bittest.cintrincs/bittestc.c intrincs/bittestci.c intrincs/bittestr.c intrincs/bittestri.c \ intrincs/bittests.c intrincs/bittestsi.c intrincs/cpuid.c intrincs/currentfiber.c intrincs/currentteb.c \ - intrincs/fiberdata.c intrincs/ilockadd.c intrincs/ilockand.cintrincs/ilockand64.cintrincs/ilockcxch.c \ + intrincs/fiberdata.c intrincs/ilockadd.c intrincs/ilockand.cintrincs/ilockand64.c\ intrincs/ilockcxch16.cintrincs/ilockcxch64.cintrincs/ilockcxchptr.cintrincs/ilockdec.c intrincs/ilockdec16.c \ intrincs/ilockdec64.c intrincs/ilockexch.c intrincs/ilockexch64.c intrincs/ilockexchadd.c intrincs/ilockexchadd64.c \ intrincs/ilockexchptr.c intrincs/ilockinc.c intrincs/ilockinc16.c intrincs/ilockinc64.cintrincs/ilockor.c\ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
Erik van Pienbroek schreef op za 25-05-2013 om 20:46 [+0200]: Here's a really minimal testcase which demonstrates the problem: $ touch foo.c $ i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--export-all-symbols $ i686-w64-mingw32-objdump -p foo.dll snip [Ordinal/Name Pointer] Table [ 0] InterlockedCompareExchange@12 [ 1] _InterlockedCompareExchange snip So even when an empty library is built it will export the two InterlockedCompareExchange symbols.. Any news on this issue? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
2013/6/10 Erik van Pienbroek e...@vanpienbroek.nl: Erik van Pienbroek schreef op za 25-05-2013 om 20:46 [+0200]: Here's a really minimal testcase which demonstrates the problem: $ touch foo.c $ i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--export-all-symbols $ i686-w64-mingw32-objdump -p foo.dll snip [Ordinal/Name Pointer] Table [ 0] InterlockedCompareExchange@12 [ 1] _InterlockedCompareExchange snip So even when an empty library is built it will export the two InterlockedCompareExchange symbols.. Any news on this issue? I will take a look to this this evening. We will need to remove here the alias-code to fix that Kai -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
On Fri, May 24, 2013 at 5:29 AM, Erik van Pienbroek e...@vanpienbroek.nl wrote: Hi, During review of one of our Fedora packages we noticed an unexpected change in behavior in recent mingw-w64 trunk snapshots. We noticed that several libraries which were built against recent mingw-w64 trunk snapshots suddenly started to export the symbols _InterlockedCompareExchange and InterlockedCompareExchange@12 in their shared libraries. Libraries which now show this behavior in Fedora are: * libasprintf-0.dll (gettext) * libcrypto-10.dll (openssl) * libffi-6.dll * libgmp-10.dll * libgnutls-xssl-0.dll * libgnutlsxx-28.dll * libintl-8.dll (gettext) * libobjc-4.dll (gcc) * libpixman-1-0.dll * libspice-controller-0.dll (spice) * libsqlite3-0.dll * libusb-1.0.dll (libusbx) * QtUiTools4.dll (qt4) The thing all these libraries have in common that they were built against recent mingw-w64 snapshots. The issue can be illustrated by opening the dll in question in dependency walker or by running objdump: i686-w64-mingw32-objdump -p /usr/i686-w64-mingw32/sys-root/mingw/bin/libsqlite3-0.dll | grep -B1 Interlocked [Ordinal/Name Pointer] Table [ 0] InterlockedCompareExchange@12 [ 1] _InterlockedCompareExchange So far I've only seen this happening for the i686-w64-mingw32 target. I can't confirm yet if it also is happening on x86_64-w64-mingw32. Yes, I can see this happening for the i686-w64-mingw32 target for compile glib 2.36.2, but x86_64-w64-mingw32 target not take effected. It's really annoying. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
Erik van Pienbroek schreef op do 23-05-2013 om 23:29 [+0200]: Hi, During review of one of our Fedora packages we noticed an unexpected change in behavior in recent mingw-w64 trunk snapshots. We noticed that several libraries which were built against recent mingw-w64 trunk snapshots suddenly started to export the symbols _InterlockedCompareExchange and InterlockedCompareExchange@12 in their shared libraries. Here's a really minimal testcase which demonstrates the problem: $ touch foo.c $ i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--export-all-symbols $ i686-w64-mingw32-objdump -p foo.dll snip [Ordinal/Name Pointer] Table [ 0] InterlockedCompareExchange@12 [ 1] _InterlockedCompareExchange snip So even when an empty library is built it will export the two InterlockedCompareExchange symbols.. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
