From: Eli Z. <el...@gn...> - 2017-09-07 15:31:20
|
Re recent discussions about DLL dependencies in GCC binary distribution: I installed today GCC 6.3.0 from the MinGW site, including all of its dependency libraries, and suddenly GDB started crashing. It turns out GDB depends on libgmp, and the latest libgmp-10.dll I installed as part of GCC upgrade depends on libgcc_s_dw2-1.dll, which somehow causes these crashes, perhaps because GDB is linked statically against libgcc. The solution was to move libgmp-10.dll that came with GCC 6 to libexec, where the binaries that need it live, and then downgrade libgmp in the public bin directory to an earlier version that does not depend on libgcc DLL. Just another day in DLL hell^H^H^H^Hparadise. P.S. Many thanks to Keith for providing this new GCC version. |
From: Keith M. <kei...@us...> - 2017-09-07 18:32:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/09/17 16:31, Eli Zaretskii wrote: > [Dynamically linked libgmp-10.dll causes GDB to crash] > > The solution was to move libgmp-10.dll that came with GCC 6 to > libexec, where the binaries that need it live, and then downgrade > libgmp in the public bin directory to an earlier version that does not > depend on libgcc DLL. Which previous version of libgmp-10.dll were you using? Currently visible in our FRS, I see (most recent first): - - libgmp-6.1.2-1-mingw32-dll-10 - - gmp-5.1.2-1-mingw32-dll (provides libgmp-10.dll + libgmpxx-4.dll) - - libgmp-5.0.1-1-mingw32-dll-10 Of these, both the GMP-6.1.2 and GMP-5.1.2 DLL versions are dynamically linked against libgcc_s_dw2-1.dll; only the GMP-5.0.1 version appears to be statically linked, (while curiously, and inconsistently, its corresponding libgmpxx-4.dll is dynamically linked). > Just another day in DLL hell^H^H^H^Hparadise. Or maybe another example of how badly broken libgcc_s_dw2-1.dll (from upstream) remains to this day; perhaps it would be prudent to specify - -static-libgcc, to avoid this turd as much as possible, in all of our binary package builds? > P.S. Many thanks to Keith for providing this new GCC version. You're welcome. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZsZCpAAoJEMCtNsY0flo/bz0P/0g44BI/g5ssrTDyGI0pHfWR Ml10Lg9jVvmX4aFrymAAx/7pC5vIp4DvUcnRu+4kUrzzF1y7PC0TICMNIt3kpvBh YOWHftWtGTaMz1oKU/vRgeSZO3KeSpoTveCn8Fl3Pik4hhvtzOvIorvsoVphEHOb 70WLpSPQXwf8lJP3yfsDJqbkqRnfe59IykWCzDDXxwJLR57Meg5YObrrQqsZqTJ0 2KrPe99IDbpu2j2nNTx2ng9XTyXPtKPgmL7FOvSSlNupWPiaCptb4xZwsSENSazp iLP0v3qF82yfxsQE+ED9Z+gg4De+Da7Gx2qWDeKgXIL7mPO+bNIXcg6iGST0+HBF /gqs2iETPDWb1dbdqRAyE6lnfa7I2W6yhLDjPt7RiYfezREr4RyKvhTPON3ZgS3b bp9bshdV1BL6yztdKmq5IN177Z98QO0/ka2f45jyTn82/2Dr1mtppHgwYCsZkur+ GYUuiq8TzM/Rqe/f54QkZjiommaPKfl81Gf7klkk6M8rkAbjx/WLB01ZS8cSoWxH ErWtbJQeURx58ZHaEZa/NYAbf+Yr6UhXWYDkSwLvmij1qPG8F3y79QVI0dmX58xu abkwrGVu2uGoW+WzqmFyiyZ0T3S1/q6LIc5+l4tOb04Zed8CsZHN5j6wBepy86rH hNDmDel0/aR/onGFvmvV =75cM -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2017-09-07 19:09:11
|
> Date: Thu, 7 Sep 2017 19:32:09 +0100 > From: Keith Marshall via MinGW-users <min...@li...> > > Which previous version of libgmp-10.dll were you using? I compiled it myself (quite some time ago), the binaries are here: https://sourceforge.net/projects/ezwinports/files/gmp-5.0.2-w32-bin.zip/download > > Just another day in DLL hell^H^H^H^Hparadise. > > Or maybe another example of how badly broken libgcc_s_dw2-1.dll (from > upstream) remains to this day; Sadly, yes. I actually thought these problems are long gone, since about a year or even more ago, I worked with GCC developers to make a change there that was supposed to fix this problem. I guess not. > perhaps it would be prudent to specify -static-libgcc, to avoid > this turd as much as possible, in all of our binary package builds? I'd recommend that, yes. That's what I do in all the packages I put on the ezwinports site. |
From: Keith M. <kei...@us...> - 2017-09-07 19:56:41
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/09/17 20:08, Eli Zaretskii wrote: >> Date: Thu, 7 Sep 2017 19:32:09 +0100 >> From: Keith Marshall via MinGW-users <min...@li...> >> >> Which previous version of libgmp-10.dll were you using? > > I compiled it myself (quite some time ago), the binaries are here: > > https://sourceforge.net/projects/ezwinports/files/gmp-5.0.2-w32-bin.zip/download So, pretty old then; in the meantime, we've published GMP-5.1.2 and GMP-6.1.2 variants. >>> Just another day in DLL hell^H^H^H^Hparadise. >> >> Or maybe another example of how badly broken libgcc_s_dw2-1.dll (from >> upstream) remains to this day; > > Sadly, yes. I actually thought these problems are long gone, since > about a year or even more ago, I worked with GCC developers to make a > change there that was supposed to fix this problem. I guess not. No. We've seen the effect quite recently: when I built libmingwex-0.dll with a dynamic libgcc dependency, it caused a trivial Ada test program to crash; rebuilding without that dependency avoided that problem. >> perhaps it would be prudent to specify -static-libgcc, to avoid >> this turd as much as possible, in all of our binary package builds? > > I'd recommend that, yes. That's what I do in all the packages I put > on the ezwinports site. How did you get libtool to pass the -static-libgcc flag through to the linker? I just tried a rebuild, with it within the CFLAGS, and libtool cavalierly discarded it. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZsaRwAAoJEMCtNsY0flo/dzkQAJ2RFOdmqmegObBAcwDkcpF9 dbrWvP2UrxpL6EDDM+uXrfrqulaAkySs1eYdhaaaGFbuTFUWGHKVwrq8cLsC2ts7 S+u4k65x5pKIgXgqG4aPBq8muIMiiFkEqSOkZkIZirZrM07wrWARAtrxEEw3ZsWU aquTLTWyyZ0QLeWYzVC0fIqgNTSC8hAahK9ER10cEeXcAArAn4RcVubRuPlHHoPS C44QxAoYncBYC5OLsOY8Dc/0x9CXqXAVKcb+5JBl9u61lMuXaj2pDbjIeHux/bHe PHFZafc2hADGmiSJx+rzKbDoOB0JQsxPfmzOlqSUq7OfTnt9sm2Vs/KVkbILWpr+ b3ntqNqbdGdiLycNLu8apaL7pWiijw8h3iXeGaPfew6VJ8WwrwYBnjPBVplKbZc9 tDj2qo5vIs6o3NqOlG7+CWNPAgPVVsJE6UCemWqc/lZrdbTFiJ8OBXVd+woScf+6 YQksBoCcyNZc9jsqoX18r94wsarvXYE1If1Ag8mDGyb9YegU2FdL7+3eI8vuGTCs 52G1ERAvqiByxpaQQCEO0/05QF0EkbVWodELEONn9mj04o8Z4qrE/t1M2LluFyZ7 CCMOsp9dMfGgxIt8fbmUBsLaS6KLMx0c5/3RhGkCzJonKv7GDmeju3wmhqsZqpLU jwNDMP6G+yX45TNbyZyN =vnYm -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2017-09-07 20:12:16
|
> Date: Thu, 7 Sep 2017 20:56:33 +0100 > From: Keith Marshall via MinGW-users <min...@li...> > > > https://sourceforge.net/projects/ezwinports/files/gmp-5.0.2-w32-bin.zip/download > > So, pretty old then; in the meantime, we've published GMP-5.1.2 and > GMP-6.1.2 variants. Yes. But since the DLL still has the same -10 version, they should be compatible. Maybe I will build a newer version soon, building GMP is easy enough. > > Sadly, yes. I actually thought these problems are long gone, since > > about a year or even more ago, I worked with GCC developers to make a > > change there that was supposed to fix this problem. I guess not. > > No. We've seen the effect quite recently: when I built libmingwex-0.dll > with a dynamic libgcc dependency, it caused a trivial Ada test program > to crash; rebuilding without that dependency avoided that problem. In my case, it as an abort, not a crash. So maybe it's a slightly different problem: the previous one was a SIGSEGV. > >> perhaps it would be prudent to specify -static-libgcc, to avoid > >> this turd as much as possible, in all of our binary package builds? > > > > I'd recommend that, yes. That's what I do in all the packages I put > > on the ezwinports site. > > How did you get libtool to pass the -static-libgcc flag through to the > linker? I just tried a rebuild, with it within the CFLAGS, and libtool > cavalierly discarded it. Yeah, libtool is tricky, it removes any CFLAGS it wasn't taught about. See this HOWTO (which you will remember you coached me to post): http://www.mingw.org/wiki/HOWTO_Sneak_GCC_Switches_Past_Libtool |
From: Keith M. <kei...@us...> - 2017-09-08 13:30:18
Attachments:
gmp-6.1.2-tests.log
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/09/17 21:11, Eli Zaretskii wrote: >> Date: Thu, 7 Sep 2017 20:56:33 +0100 >> From: Keith Marshall via MinGW-users <min...@li...> >> >>> https://sourceforge.net/projects/ezwinports/files/gmp-5.0.2-w32-bin.zip/download >> >> So, pretty old then; in the meantime, we've published GMP-5.1.2 and >> GMP-6.1.2 variants. > > Yes. But since the DLL still has the same -10 version, they should > be compatible. Mostly, yes, to the extent that any application which worked with an older libgmp-10.dll *should* work with any newer ... we may reasonably expect *backward* compatibility, but *forward* isn't guaranteed. >> [previously reported crash in trivial Ada test program] > > In my case, it as an abort, not a crash. So maybe it's a slightly > different problem: the previous one was a SIGSEGV. It was reported as a crash, but it wasn't a SIGSEGV; it was, in fact, an unhandled abort *after* the main program function had completed: https://sourceforge.net/p/mingw/mailman/message/35696716/ >> How did you get libtool to pass the -static-libgcc flag through to >> the linker? I just tried a rebuild, with it within the CFLAGS, and >> libtool cavalierly discarded it. > > Yeah, libtool is tricky, it removes any CFLAGS it wasn't taught about. > See this HOWTO (which you will remember you coached me to post): > > http://www.mingw.org/wiki/HOWTO_Sneak_GCC_Switches_Past_Libtool I've no more than a dim recollection; thanks for the reminder! Applying that, I've rebuilt libgmp-10.dll and libgmpxx-4.dll, *without* their dependencies on libgcc_s_dw2-1.dll. (I wasn't able to eliminate the libstdc++-6.dll dependency from libgmpxx-4.dll, and when I tried to do so, not only did the dependency remain, but it became impossible to build the associated test suite module ... due to multiple definitions of publicly visible library symbols appearing in the linked image). I've the output from the test suite, when run (under wine) on the rebuilt DLLs; note that there is one failure among the libgmp-10.dll specific tests, (which I know to be due to wine's broken sscanf() implementation), and three among the libgmpxx-4.dll specific tests, (which may, or may not, be due to wine bugs). The rebuilt DLLs, themselves, are too big for mailing list attachments, so I've posted them to FRS ... look for 6.1.2-2 version identifiers, within the same gmp-6.1.2 package directory as the 6.1.2-1 originals. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZsptSAAoJEMCtNsY0flo/lfwP+wdySC7NESW2NXb/ArGgxpz6 zBikeQM3Fz0fUzT6MBmTnt2OnfeCk21egCvLoD+IHqXcRZXV4+Fftjw3QunRwUCE ZzLo5ngXWTPhcVfjeCWGI2RTS61jxNLmNXGTwterC8z6iHEgJ+RvWYtoEvnz8wzf 7L6oyrFaSNy5fUu+ANn0KJbgkRiGHjdYGNZuo/jOoBnkVusj+VOrPgk1scp5ADnU +B+X7MVAYvx9zgmEXV2XyU0VWPTyuBVksN3cCoBk8qtbn9sukLlUFbxewtAPC4Al mCon9Udcria3yvOUz0hyn0WwHgPqLKNAMOY7yqYJO/TptCbGX9YWFcsrSlNtEA45 pmqmjzk9Smx3M8KnjP65NCvKXnbe6uPtuXS109+v8K+wuTMCoMNzkg/pwQHepQdR W2l3gCAmimVbxjAufzfsY3llDAVBPMw4eOHq+sLDuHRIB6rcOcLK09cMDhMp8RMP pUK5cA/7QMx4vOK6NxdLOoQ1owV/5LAoWTh1HDCOcYI/jve/9RuDV4JWcOdBiaTK K4CH/WwNBanTg3Gp6wjuAYeo5TEWO/TfpBqOBr+1xyvTzuuxzJA+jZlylApqzjCg 75bKeBxmAeMmtMdm9GKCi1On6o81lp4p9CkFBTdlgXNx6LMMGRW90TnI+x/uUGe9 fma37mhSLd40T4oQZjoD =y+Yk -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2017-09-08 14:32:35
|
> Date: Fri, 8 Sep 2017 14:29:54 +0100 > From: Keith Marshall via MinGW-users <min...@li...> > > > http://www.mingw.org/wiki/HOWTO_Sneak_GCC_Switches_Past_Libtool > > I've no more than a dim recollection; thanks for the reminder! > > Applying that, I've rebuilt libgmp-10.dll and libgmpxx-4.dll, *without* > their dependencies on libgcc_s_dw2-1.dll. Great. > (I wasn't able to eliminate > the libstdc++-6.dll dependency from libgmpxx-4.dll, and when I tried to > do so, not only did the dependency remain, but it became impossible to > build the associated test suite module ... due to multiple definitions > of publicly visible library symbols appearing in the linked image). That matches my experience: in general C++ DLLs cannot be statically linked against these libraries. That's why I sometimes provide only static versions of those C++ libraries, not DLLs. > The rebuilt DLLs, themselves, are too big for mailing list > attachments, so I've posted them to FRS ... look for 6.1.2-2 version > identifiers, within the same gmp-6.1.2 package directory as the > 6.1.2-1 originals. Maybe it would be a good idea to make a minor new release available from the MinGW site? Thanks. |
From: Keith M. <kei...@us...> - 2017-09-08 15:20:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/09/17 15:32, Eli Zaretskii wrote: >> The rebuilt DLLs, themselves, are too big for mailing list >> attachments, so I've posted them to FRS ... look for 6.1.2-2 version >> identifiers, within the same gmp-6.1.2 package directory as the >> 6.1.2-1 originals. > > Maybe it would be a good idea to make a minor new release available > from the MinGW site? Effectively, that's there already; nothing needs to change, apart from the two new DLL packages, (and their accompanying GPG signatures), but obviously, it would be better to rename everything with a 6.1.2-2 id tag, and add a mingw-dist (mingw-get) update record to deliver it. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZsrVMAAoJEMCtNsY0flo/FqQQAMw+kSAmHwpdlW4UL/Lk2vqW ip+m2rNjPdTZiLEYPHCv0nyzxOhe+ZkAVSf9l50JNzlkxRjk3eMGIHCVqRBmKVo2 k4al3wr7AnXqm/4ifyQcGGBD7wmK5eTrm28yrB59lHX3IEdbaCfdgNJvXqc8dtJL pPKizfIu8ViKIsSe8p6jL1+GXPenUZdNkDVSdNyWazbEv9QbvcR5MhE87oTAXU3s gZfC1DgDYawENQCkceWAqCZCDDs6yQ8ydNycSM+KKzzcPBVyBaRXgiqipGZc9mei 8vmNjzuwfIT9tyZf41FkP6Dc0kP6jwJRPrVyC2zu9X81SFmwFeYhCFMF6XXfmSRS 2MeIVZN/+Z4I10wn1kjUfVxpI9Pk89MhBsOmFPywilL2tL4ormTTKtjGcCBBNK/g 7FZK4qEpOMZUgxVS49d5mYmtqE/t2YwmNrksCCNsteXxi+E60L7SG6/cyJuCyS/C M1W5RmS7YpgvSxlS5je92Xrmt3HMKqycZd5lMRN8+F7EwBabqTja4y1KyvZrLHvv c3+cf/yyBgBmHVGR16V+anbtmC3gmwg72VVSDMXpo2DgT48TY5J8PWkwOfBJPVxP JmpHbQoQ2DGYd+zdtWv4M59d4KmJOfVnUT6gkLJEpV/9PCc9aykgtLR3AJrkmDze FH4lhEwQ4IKeJFNx5Bzk =zu5W -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-09-08 22:52:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/09/17 16:20, Keith Marshall via MinGW-users wrote: > On 08/09/17 15:32, Eli Zaretskii wrote: >>> The rebuilt DLLs, themselves, are too big for mailing list >>> attachments, so I've posted them to FRS ... look for 6.1.2-2 version >>> identifiers, within the same gmp-6.1.2 package directory as the >>> 6.1.2-1 originals. > >> Maybe it would be a good idea to make a minor new release available >> from the MinGW site? > > Effectively, that's there already; nothing needs to change, apart from > the two new DLL packages, (and their accompanying GPG signatures), but > obviously, it would be better to rename everything with a 6.1.2-2 id > tag, and add a mingw-dist (mingw-get) update record to deliver it. I've done that now; mingw-get should install this updated version. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZsx9HAAoJEMCtNsY0flo/tX4P/2gpw3KJSw8RCsZYHbZSd5JQ Vc/M+XiwgOZ7VoQsf7t63fPMgTzENrkSoj9cEeO6gs9nnGBGCBj9nPt2nW2KWeIc l9GymBs3ZADEZDaUpONXSYJPPdGdL3tEctHurVEhUn+mP7WP1eucevHT4Y2cWuBB /0F8AzSv9vLgNdn+02BCqht4EVtmVUESKCBdnu8DWgEa/L1Gd1yx23zvdM4Njb83 NcR5iWOeOHSZbXJOnzA41zeugovmljbrUkdG+/2rT6JG11ie8HeLjKuC0ciZIXE8 VXtg0ncLy0rX1QhlZ3b1z4NBQ9+JDG2rVL1x5LanF6WNrK5rASTj7KWREMUah+fL 6SAu1ZZ6PKrj+7CYy7LTjbB8VpHE0bWExos+RUM13R3ppR6otKHjBHjF/xIe9XEC v7pOPZ+315Pl/pH70J5pAK6Ax35WmfOW/+7e+mNH2gXuBSIHPHJNNwtrS7kCIQJ0 Xp6Kfp0KC+LYOsJg3AEleUONTeLJP7wlxSqZ7dSQDQ5RZe7TpO6/23BQAa3zTJcs stfO8PX66kipQtxSQUSNpJ167r+XpxmatB8Lpv32VpwbS21IF6odKqvKQ4rmsRxv Rehc4XsYjQwzB9qADjDgLORnx3k/t9zf1SmERPR3zh149wfzsY5Qpi8UU2n/5bk7 NuNeQMsPmWXiFffhO/YW =A8d5 -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2017-09-09 06:52:28
|
> Date: Fri, 8 Sep 2017 23:52:55 +0100 > From: Keith Marshall via MinGW-users <min...@li...> > > >> Maybe it would be a good idea to make a minor new release available > >> from the MinGW site? > > > > Effectively, that's there already; nothing needs to change, apart from > > the two new DLL packages, (and their accompanying GPG signatures), but > > obviously, it would be better to rename everything with a 6.1.2-2 id > > tag, and add a mingw-dist (mingw-get) update record to deliver it. > > I've done that now; mingw-get should install this updated version. Great, thanks. |