From: Chris S. <ir0...@gm...> - 2009-12-09 17:55:16
|
Hi All, Kai has provided a patch for mingwrt that implements TLS Callbacks. He also took 9x/Me into consideration and believes they will still work (I don't have access to a 9x/Me machine so I can't validate it). Beyond the changes to mingwrt, gcc/g++ will also need to be recompiled and linked against the new startup code. I believe a more recent version of gcc/g++ will also be needed to fix a bug in gcc/g++. As I understand it one of the following releases is required: need gcc-4.3.4 (gcc-4_3-branch r149015) or gcc-4.4.1 (gcc-4_4-branch r149016) or gcc-4.5.x (trunk r149593) or newer which have a properly fixed gcc/emutls.c Aaron, would you be willing to spin a new gcc release? If so, I can commit the patch provided by Kai to enable the TLS callbacks in mingwrt. Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Kai T. <kti...@go...> - 2009-12-11 11:35:07
|
Hello, I added the TLS patch, I've sent already to Danny and Chris, to the patch tracker as 2912598. So everybody can try and possibly verify that Win9X/Me are working, too. To have full advantage of this patch the shared libraries of gcc (at least libgcc_s...) should be relinked against patched runtime. Otherwise please use '-static' option for tests. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Chris S. <ir0...@gm...> - 2009-12-15 17:21:18
|
Hi Kai, > I added the TLS patch, I've sent already to Danny and Chris, to the > patch tracker as 2912598. So everybody can try and possibly verify > that Win9X/Me are working, too. To have full advantage of this patch > the shared libraries of gcc (at least libgcc_s...) should be relinked > against patched runtime. Otherwise please use '-static' option for > tests. Thank you for adding the patch to the tracker. Aaron, do you have some time to look in to spinning a new gcc release? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Chris S. <ir0...@gm...> - 2010-01-25 03:29:24
|
>> I added the TLS patch, I've sent already to Danny and Chris, to the >> patch tracker as 2912598. So everybody can try and possibly verify >> that Win9X/Me are working, too. To have full advantage of this patch >> the shared libraries of gcc (at least libgcc_s...) should be relinked >> against patched runtime. Otherwise please use '-static' option for >> tests. > > Thank you for adding the patch to the tracker. Aaron, do you have > some time to look in to spinning a new gcc release? Since it's been well over a month since this post, I must assume that Aaron is too busy to release a new gcc for MinGW. Cesar, given your recent work with creating a new MSYS gcc toolchain, would you be interested in creating a new MinGW gcc toolchain? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Cesar S. <ces...@gm...> - 2010-01-25 13:58:24
|
Chris Sutcliffe wrote: >>> I added the TLS patch, I've sent already to Danny and Chris, to the >>> patch tracker as 2912598. So everybody can try and possibly verify >>> that Win9X/Me are working, too. To have full advantage of this patch >>> the shared libraries of gcc (at least libgcc_s...) should be relinked >>> against patched runtime. Otherwise please use '-static' option for >>> tests. >> Thank you for adding the patch to the tracker. Aaron, do you have >> some time to look in to spinning a new gcc release? > > Since it's been well over a month since this post, I must assume that > Aaron is too busy to release a new gcc for MinGW. Cesar, given your > recent work with creating a new MSYS gcc toolchain, would you be > interested in creating a new MinGW gcc toolchain? It will be a great honor for me to create a new mingw.org gcc release. I will give it a "Proposed" status initially. Is 4.4.3 OK for your purposes? I will keep you informed on my progress. I will probably ask a few questions along the way. Here are the tasks as I see it: 1) Install the build dependencies. <-- In progress 2) Build gcc itself. 3) Test it. 4) Package it. By the way, I have a working Windows 95 installation in a VirtualBox image, from and old MSDN subscription I used to have, so I can test the TLS code if need be. Cesar |
From: Chris S. <ir0...@gm...> - 2010-01-25 15:01:03
|
Hi Cesar, > It will be a great honor for me to create a new mingw.org gcc release. Excellent, thank you! > I will give it a "Proposed" status initially. I think that's reasonable. > Is 4.4.3 OK for your purposes? That would be perfect. > I will keep you informed on my progress. I will probably ask a few > questions along the way. > > Here are the tasks as I see it: > > 1) Install the build dependencies. <-- In progress > 2) Build gcc itself. > 3) Test it. > 4) Package it. > > By the way, I have a working Windows 95 installation in a VirtualBox > image, from and old MSDN subscription I used to have, so I can test the > TLS code if need be. Excellent, I will commit the TLS changes provided by Kai's patch to CVS tonight when I get home. As I understand it, before you build GCC, you will need the updated runtime from CVS to capture the TLS changes. Thank you very much for taking this on! Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Cesar S. <ces...@gm...> - 2010-03-14 00:21:49
|
Cesar Strauss wrote: > It will be a great honor for me to create a new mingw.org gcc release. I just released a snapshot of gcc 4.5.0. It is available at: MinGW Proposed -> gcc-4.5.0_20100311-1 Direct link: https://sourceforge.net/projects/mingw/files/MinGW%20Proposed/ Release Notes: https://sourceforge.net/projects/mingw/files/MinGW%20Proposed/gcc-4.5.0_20100311-1/gcc-4.5.0_20100311-1-mingw32.RELEASE_NOTES.txt/view > I will give it a "Proposed" status initially. I will appreciate any comments from the MinGW developers before I release it officially. Cesar |
From: John E. / T. <td...@td...> - 2010-03-14 06:03:38
|
On 3/13/2010 5:20 PM, Cesar Strauss wrote: > I just released a snapshot of gcc 4.5.0. ... > I will appreciate any comments from the MinGW developers before I > release it officially. > My comprehensive exceptions + DLLs + threads test fails with error "0xC0000005" (unable to start correctly). OS is Win 7 64-bit (therefore 32-bit emulation). Compilation command line: g++ -shared-libgcc -shared -o test.dll -Wl,--out-implib,libtest.dll.a test2.cpp g++ -shared-libgcc -o test.exe test.cpp libtest.dll.a This test works fine for me with any recent TDM-GCC release, as well as with the MinGW 3.4.5-20060117 release(s) (using -mthreads option, of course). It does *not* work with the MinGW 4.4.0 release (crashes in the secondary thread). Looking at the verbose output, I don't see any reference to -lgcc_eh (libgcc_eh.a) -- typically seen when using a shared version of libgcc -- could be related? Testcase sources attached (test.cpp, test2.cpp). At least on my system, libstdc++ doesn't fully support files or streams larger than ~2GB (2^32 - 1 bytes). I had a working patch for this in TDM-GCC, but now on my current dev machine, neither TDM-GCC nor this 4.5.0 release can go past the 2GB limit for some reason. (Maybe something to do with the aforementioned 32-bit emulation?) There is a testcase at <http://sourceforge.net/tracker/?func=detail&aid=2803234&group_id=200665&atid=974439>. Looking at the current trunk sources, it appears line 275 of libiberty/make-relative-prefix.c will still cause the CWD to be detected as the root of the GCC installation if it contains a file or folder with the same name as the driver program being used (i.e. "gcc", "g++", etc.). This bug is rarely seen but incredibly painful to diagnose, and happens because the "X_OK" flag in the call to access() is ignored on Windows. The patch I've been using in TDM-GCC is attached (make-rel-pref.patch; only applies cleanly to 4.4). Of these three issues, the first two I see as fairly critical and the last one as not-so-critical. I'd be happy to run further tests if the need arises, but unfortunately I don't currently have any time to build GCC myself. Cheers, John E. |
From: Cesar S. <ces...@gm...> - 2010-03-14 14:30:49
|
John E. / TDM wrote: > My comprehensive exceptions + DLLs + threads test fails with error > "0xC0000005" (unable to start correctly). OS is Win 7 64-bit (therefore > 32-bit emulation). Compilation command line: > g++ -shared-libgcc -shared -o test.dll -Wl,--out-implib,libtest.dll.a > test2.cpp > g++ -shared-libgcc -o test.exe test.cpp libtest.dll.a Thanks for the test case. I made it to work by adding -Wl,--enable-auto-import. Using -static-libstdc++ also works. Thanks to SquallATF for the hint: [ mingw-Bugs-2970208 ] gcc 4.5.0 build gmp 5.0.1 cxx test get 0xc0000005 error https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2970208&group_id=2435 Cesar |
From: Danny S. <dan...@cl...> - 2010-03-14 20:09:55
|
> > My comprehensive exceptions + DLLs + threads test fails with error > "0xC0000005" (unable to start correctly). OS is Win 7 64-bit (therefore > 32-bit emulation). Compilation command line: > g++ -shared-libgcc -shared -o test.dll -Wl,--out-implib,libtest.dll.a > test2.cpp > g++ -shared-libgcc -o test.exe test.cpp libtest.dll.a > This test works fine for me with any recent TDM-GCC release, as well as > with the MinGW 3.4.5-20060117 release(s) (using -mthreads option, of > course). It does *not* work with the MinGW 4.4.0 release (crashes in the > secondary thread). Looking at the verbose output, I don't see any > reference to -lgcc_eh (libgcc_eh.a) -- typically seen when using a > shared version of libgcc -- could be related? Testcase sources attached > (test.cpp, test2.cpp). > Your test works for me. It should work for you if you: (1) Use a binutils that supports -enable-runtime-pseudo-reloc-v2 and make it the default. This switch is undocumented. (2) Use a mingw runtime with this change: 2009-03-05 Kai Tietz <kai...@on...> * pseudo-reloc.c: Rewrite to enable pseudo_reloc version 2. With those conditions, the lack of an -enable-auto-import switch does not cause the 0xc0000005 error that ld warns about here: "warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing" If you want to make --enable-auto-import the default, which makes sense with Kai's pseudo-reloc fixes, the place to do it is in src/ld/pe.em (not in gcc specs). Danny |
From: Cesar S. <ces...@gm...> - 2010-03-14 23:38:49
|
Danny Smith wrote: >> My comprehensive exceptions + DLLs + threads test fails with error >> "0xC0000005" (unable to start correctly). OS is Win 7 64-bit (therefore >> 32-bit emulation). Compilation command line: >> g++ -shared-libgcc -shared -o test.dll -Wl,--out-implib,libtest.dll.a >> test2.cpp >> g++ -shared-libgcc -o test.exe test.cpp libtest.dll.a > > Your test works for me. It should work for you if you: > > (1) Use a binutils that supports -enable-runtime-pseudo-reloc-v2 and make > it the default. This switch is undocumented. > Yes, it works for me if I add -Wl,--enable-runtime-pseudo-reloc-v2. For the record, my new command line is: $ g++ -shared-libgcc -shared -o test.dll -Wl,--out-implib,libtest.dll.a test2.cpp -Wl,--enable-runtime-pseudo-reloc-v2 $ g++ -shared-libgcc -o test.exe test.cpp libtest.dll.a -Wl,--enable-runtime-pseudo-reloc-v2 Binutils version is 2.20.1. MinGW Runtime is 3.18. > With those conditions, the lack of an -enable-auto-import switch does not > cause the 0xc0000005 error that ld warns about here: > > "warning: auto-importing has been activated without --enable-auto-import > specified on the command line. > This should work unless it involves constant data structures referencing" Does it makes sense, then, to avoid printing this warning on MinGW, when runtime-pseudo-reloc-v2 is used? Regards, Cesar |
From: Keith M. <kei...@us...> - 2010-01-25 21:28:33
|
On Monday 25 January 2010 03:29:15 Chris Sutcliffe wrote: > > Aaron, do you have some time to look in to spinning a new gcc > > release? > > Since it's been well over a month since this post, I must assume > that Aaron is too busy to release a new gcc for MinGW. Chris, Aaron advised us, some time ago, that he no longer felt able to devote time to maintaining MinGW's GCC releases; the baton was passed to John E. As yet, we've had no indication of John's plans for an official MinGW release to supercede Aaron's GCC-4.4.0. On Monday 25 January 2010 13:58:11 Cesar Strauss wrote: > It will be a great honor for me to create a new mingw.org gcc > release. Cesar, Your willingness, (indeed your enthusiasm), for taking this on is refreshing. Thank you for the offer; I am sure we can anticipate a high standard, on a par with your work on MSYS. > I will give it a "Proposed" status initially. > Is 4.4.3 OK for your purposes? Seems ideal to me. > I will keep you informed on my progress. I will probably ask a few > questions along the way. It may be politic to give John E. an opportunity to either accede responsibility to you, or for you to agree joint responsibilities. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2010-01-25 23:04:20
|
Hi Keith, > Aaron advised us, some time ago, that he no longer felt able to > devote time to maintaining MinGW's GCC releases; the baton was > passed to John E. As yet, we've had no indication of John's plans > for an official MinGW release to supercede Aaron's GCC-4.4.0. Ah, I missed that, thank you for pointing it out. > Your willingness, (indeed your enthusiasm), for taking this on is > refreshing. Thank you for the offer; I am sure we can anticipate a > high standard, on a par with your work on MSYS. Indeed! > It may be politic to give John E. an opportunity to either accede > responsibility to you, or for you to agree joint responsibilities. Cesar / John E., I've committed Kai's TLS patch to the mingw-runtime CVS, so please use it when building the new GCC. If you'd like a tarball of mingw-runtime as opposed to pulling it from CVS and building it, please let me know. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org |
From: John E. / T. <td...@td...> - 2010-01-26 01:15:13
|
On 1/25/2010 2:28 PM, Keith Marshall wrote: > Aaron advised us, some time ago, that he no longer felt able to > devote time to maintaining MinGW's GCC releases; the baton was > passed to John E. As yet, we've had no indication of John's plans > for an official MinGW release to supercede Aaron's GCC-4.4.0. > Regrettably, I have none. > On Monday 25 January 2010 13:58:11 Cesar Strauss wrote: > >> I will keep you informed on my progress. I will probably ask a few >> questions along the way. >> > It may be politic to give John E. an opportunity to either accede > responsibility to you, or for you to agree joint responsibilities. > I would absolutely relinquish management of MinGW's GCC releases, all parties being willing. I have less time than ever to devote to GCC hacking (or hobbyist programming of any sort), so anyone who is (a) familiar with building GCC and (b) willing to do so for MinGW has my blessing. Cesar, there are a few patches extant in the most recent TDM-GCC release (4.4.1-tdm-2; download the patches at [1]) that fix breaking issues present in the official MinGW 4.4.0 release. I mention this because you may find them useful as indicators of common issues and as starting points for appropriate upstream fixes. Some of the problems they address may have already been fixed in 4.4.2 or 4.4.3; I haven't checked. I would be ecstatic if an upcoming official release had some form of fix that allows exceptions to propagate out of DLLs without requiring shared versions of libgcc and libstdc++ (this is what ehstatic.patch does in TDM-GCC). However, I don't recall any other MinGW developers expressing support for this. That's all I can think of for now. If you post issues to MinGW-dvlpr that I've encountered before, I'll try to address them. -John E. [1] <http://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/4.4.1-tdm-2/gcc-4.4.1-tdm-2-srcbase.zip/download> |
From: Cesar S. <ces...@gm...> - 2010-01-27 01:13:16
|
John E. / TDM wrote: > On 1/25/2010 2:28 PM, Keith Marshall wrote: >> It may be politic to give John E. an opportunity to either accede >> responsibility to you, or for you to agree joint responsibilities. >> Sure. > I would absolutely relinquish management of MinGW's GCC releases, all > parties being willing. I have less time than ever to devote to GCC > hacking (or hobbyist programming of any sort), so anyone who is (a) > familiar with building GCC and (b) willing to do so for MinGW has my > blessing. > Thanks, I'll do my best. > Cesar, there are a few patches extant in the most recent TDM-GCC release > (4.4.1-tdm-2; download the patches at [1]) that fix breaking issues > present in the official MinGW 4.4.0 release. I mention this because you > may find them useful as indicators of common issues and as starting > points for appropriate upstream fixes. Some of the problems they address > may have already been fixed in 4.4.2 or 4.4.3; I haven't checked. OK, I'll have a look. Aaron's 4.4.0 release also had patches of its own, for building a shared libstdc++ and for throwing exceptions through foreign frames, it seems. On the other hand, I'd rather avoid local patches, if possible, as I don't think I have the skill and time to port them to a newer release. > > That's all I can think of for now. If you post issues to MinGW-dvlpr > that I've encountered before, I'll try to address them. > Thank you, I appreciate it. Cesar |
From: Charles W. <cwi...@us...> - 2010-01-26 02:04:24
|
John E. / TDM wrote: > I would be ecstatic if an upcoming official release had some form of fix > that allows exceptions to propagate out of DLLs without requiring shared > versions of libgcc and libstdc++ (this is what ehstatic.patch does in > TDM-GCC). However, I don't recall any other MinGW developers expressing > support for this. To reiterate the reasons for the lack of support for that patch (which is not to say "opposition", just lack of explicit support): 1. It originated with Danny back in the 3.x days, and during the 3.x->4.0 transition he said: On 4/20/2006 at 2:49 PM, Danny wrote: > On 4/20/2006 at 11:23 AM, Chuck wrote: >> Do you have a forward port [ed: to gcc-4.x] of your latest >> exceptions-across-dll-bounds >> patch (e.g. the 3.4.5-based one referred to in this >> http://lists.zerezo.com/mingw-users/msg02554.html message, >> that implements >> >> (1) Extend the global shared_ptr stucture to handle the >> __cxa_eh_globals > > Yes. Against trunk pre-Christmas [ed: 12/2006]. But. I've finally > convinced myself that the patch is more trouble than its worth. > Libstdc++/libgcc as dll's is how I work it in my own trre. So you are > on your own. 2. By extending the shared_ptr structure, you break the ABI. This means that objects (*) compiled with current mingw can't/shouldn't be used together with objects compiled with a gcc that incorporates this patch. (*) Dunno if this "prohibition" is only for C++/Java, or for all languages. Similarly, dunno if the "prohibition" is a hard one -- never do X or you'll die in interesting ways; or a soft one -- well, you can try it, and it might work. Or it might not, YMMV. And even if it works for everything you try today, it might break for someone, on something else, tomorrow. 3. There was a brief effort during Google SoC when Aaron was attempting to address this issue via another mechanism, for gcc-4.x. However, it was never completed, and the "later subproject" never materialized: http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008 "1. Exceptions across DLLs -- Item (3 libgcc_s) resolves this partially; a later subproject will extend this to non-libgcc_s cases as discussed with KT and VR" [ed: anybody know who "KT" and "VR" are?] In any case, I think the existence of this effort delayed any realistic consideration of adopting the "Danny/TDM" patch officially (by mingw.org; it's got no chance of going upstream to gcc). Maybe it's time to reconsider that, but my fear is the following: that incorporating this ABI-busting patch will ghettoize mingw-gcc-4.x, just like the Danny-patch did to mingw/cygwin-gcc-3.x. If you want to know why cygwin and mingw were so slooooooooooow to move to gcc-4.x, that patch -- and lack of a similar version in the upstream ongoing gcc development -- is a major reason why. (Which is not to be critical of Danny or John E. at all. Without that patch or something like it, gcc-3.x would have been unusable on cygwin/mingw. This is because "the right solution" -- using shared libgcc -- was not possible back then since the /other build tools/ like auto*, libtool, and ld weren't capable of building libgcc as a DLL on win32.) -- Chuck |
From: NightStrike <nig...@gm...> - 2010-01-26 02:10:06
|
On Mon, Jan 25, 2010 at 9:03 PM, Charles Wilson <cwi...@us...> wrote: > [ed: anybody know who "KT" and "VR" are?] Kai Tietz and Vince Torri |
From: Vincent R. <fo...@sm...> - 2010-01-26 10:15:20
|
On Mon, 25 Jan 2010 21:09:59 -0500, NightStrike <nig...@gm...> wrote: > On Mon, Jan 25, 2010 at 9:03 PM, Charles Wilson > <cwi...@us...> wrote: >> [ed: anybody know who "KT" and "VR" are?] > > Kai Tietz and Vince Torri > Are you sure VR doesn't mean Vincent Richomme ? |
From: NightStrike <nig...@gm...> - 2010-01-26 10:24:23
|
On Tue, Jan 26, 2010 at 5:15 AM, Vincent Richomme <fo...@sm...> wrote: > On Mon, 25 Jan 2010 21:09:59 -0500, NightStrike <nig...@gm...> > wrote: >> On Mon, Jan 25, 2010 at 9:03 PM, Charles Wilson >> <cwi...@us...> wrote: >>> [ed: anybody know who "KT" and "VR" are?] >> >> Kai Tietz and Vince Torri >> > Are you sure VR doesn't mean Vincent Richomme ? Yup, sorry, I was typing too fast. I was looking at vtorri in our IRC channel :) |
From: Danny S. <dan...@cl...> - 2010-01-27 02:33:59
|
> > Aaron's 4.4.0 release also had patches of its own, for building a shared > libstdc++ Dave Korn has committed patches to upstream gcc for shared libstdc++ See http://gcc.gnu.org/gcc-4.5/changes.html specifically, the section labelled "Operating Systems" BTW, Dave is now officially a GCC maintainer for cygwin/mingw. Kai is the other active maintainer. Danny |
From: Chris S. <ir0...@gm...> - 2010-01-27 15:29:25
|
> Dave Korn has committed patches to upstream gcc for shared libstdc++ > See > http://gcc.gnu.org/gcc-4.5/changes.html > specifically, the section labelled "Operating Systems" Since these patches are applied in 4.5, should we bypass 4.4.x and do a 'proposed' 4.5.0 release? I'm assuming Dave's patches in 4.5 have not been backported to the 4.4.x branch, so please correct me if I'm wrong. Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Kai T. <Kai...@on...> - 2010-01-27 15:40:47
|
Chris Sutcliffe <ir0...@gm...> wrote on 27.01.2010 13:39:19: > > Dave Korn has committed patches to upstream gcc for shared libstdc++ > > See > > http://gcc.gnu.org/gcc-4.5/changes.html > > specifically, the section labelled "Operating Systems" > > Since these patches are applied in 4.5, should we bypass 4.4.x and do > a 'proposed' 4.5.0 release? I'm assuming Dave's patches in 4.5 have > not been backported to the 4.4.x branch, so please correct me if I'm > wrong. > > Chris That's right. OOTB libstdc++ dll support will be available beginning from gcc version 4.5. There is at the moment no intention to back-port Dave's patches to 4.4 Kai | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | (")_(") world domination. |
From: Cesar S. <ces...@gm...> - 2010-01-27 19:19:26
|
Kai Tietz wrote: > Chris Sutcliffe wrote on 27.01.2010 13:39:19: > >>> Dave Korn has committed patches to upstream gcc for shared libstdc++ >>> See >>> http://gcc.gnu.org/gcc-4.5/changes.html >>> specifically, the section labelled "Operating Systems" >> Since these patches are applied in 4.5, should we bypass 4.4.x and do >> a 'proposed' 4.5.0 release? I'm assuming Dave's patches in 4.5 have >> not been backported to the 4.4.x branch, so please correct me if I'm >> wrong. >> >> Chris > > That's right. OOTB libstdc++ dll support will be available beginning from > gcc version 4.5. There is at the moment no intention to back-port Dave's > patches to 4.4 Pardon me, but I can't find the shared libstdc++ support in gcc trunk. I was expecting at least the -no-undefined libtool flag being present in libstdc++-v3/src/Makefile.am (*), but apparently it's not. (*) According to the patch at: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00500.html On the other hand, searching for "davek -no-undefined" in the gcc-cvs list gives commit 151781, but it's in a "cygwin-improvements" branch: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151781 Searching the libstdc++ list gives this as the most recent discussion: http://gcc.gnu.org/ml/libstdc++/2009-09/msg00102.html This seems to indicate the patch is still under review. Regards, Cesar |
From: Kai T. <kti...@go...> - 2010-01-27 19:35:08
|
2010/1/27 Cesar Strauss <ces...@gm...>: > Kai Tietz wrote: >> Chris Sutcliffe wrote on 27.01.2010 13:39:19: >> >>>> Dave Korn has committed patches to upstream gcc for shared libstdc++ >>>> See >>>> http://gcc.gnu.org/gcc-4.5/changes.html >>>> specifically, the section labelled "Operating Systems" >>> Since these patches are applied in 4.5, should we bypass 4.4.x and do >>> a 'proposed' 4.5.0 release? I'm assuming Dave's patches in 4.5 have >>> not been backported to the 4.4.x branch, so please correct me if I'm >>> wrong. >>> >>> Chris >> >> That's right. OOTB libstdc++ dll support will be available beginning from >> gcc version 4.5. There is at the moment no intention to back-port Dave's >> patches to 4.4 > > Pardon me, but I can't find the shared libstdc++ support in gcc trunk. I > was expecting at least the -no-undefined libtool flag being present in > libstdc++-v3/src/Makefile.am (*), but apparently it's not. > (*) According to the patch at: > http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00500.html > > On the other hand, searching for "davek -no-undefined" in the gcc-cvs > list gives commit 151781, but it's in a "cygwin-improvements" branch: > http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151781 > > Searching the libstdc++ list gives this as the most recent discussion: > http://gcc.gnu.org/ml/libstdc++/2009-09/msg00102.html > This seems to indicate the patch is still under review. > > Regards, > Cesar Then please check ChangeLog of libstdc++ for November/December 2009 on gcc trunk (upcoming gcc 4.5). 2009-12-17 Dave Korn <dav...@gm...> PR target/42377 * config/abi/pre/gnu.ver: Adjust mangled function signatures to permit LLP64 sizetypes throughout. 2009-11-30 Dave Korn <dav...@gm...> * testsuite/lib/libstdc++.exp (libstdc++_init): Add host-dependent settings for LC_ALL and LANG. 2009-11-30 Dave Korn <dav...@gm...> * libstdc++-v3/acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Don't disable on PE targets. * libstdc++-v3/configure: Regenerate. * libstdc++-v3/configure.host: Add libtool DLL options for Cygwin and MinGW platforms. * libstdc++-v3/include/bits/c++config (_GLIBCXX_VISIBILITY_ATTR): On platforms that don't support visibility, allow them to declare a macro _GLIBCXX_PSEUDO_VISIBILITY that is applied in place of visibility. (_GLIBCXX_PSEUDO_VISIBILITY): Supply empty default if not declared by CPU- or OS-specific headers. * libstdc++-v3/config/os/newlib/os_defines.h (_GLIBCXX_PSEUDO_VISIBILITY_default): New macro for dllimport. (_GLIBCXX_PSEUDO_VISIBILITY_hidden): New empty macro. (_GLIBCXX_PSEUDO_VISIBILITY): Evaluate to one of the above. * libstdc++-v3/config/os/mingw32/os_defines.h (_GLIBCXX_PSEUDO_VISIBILITY_default, _GLIBCXX_PSEUDO_VISIBILITY_hidden, _GLIBCXX_PSEUDO_VISIBILITY): Likewise. Regards, Kai Tietz -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Kai T. <kti...@go...> - 2010-01-27 19:43:34
|
2010/1/27 Kai Tietz <kti...@go...>: > Then please check ChangeLog of libstdc++ for November/December 2009 on > gcc trunk (upcoming gcc 4.5). > > 2009-12-17 Dave Korn <dav...@gm...> > > PR target/42377 > * config/abi/pre/gnu.ver: Adjust mangled function signatures to permit > LLP64 sizetypes throughout. > 2009-11-30 Dave Korn <dav...@gm...> > > * testsuite/lib/libstdc++.exp (libstdc++_init): Add host-dependent > settings for LC_ALL and LANG. > > 2009-11-30 Dave Korn <dav...@gm...> > > > * libstdc++-v3/acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Don't disable > on PE targets. > * libstdc++-v3/configure: Regenerate. > * libstdc++-v3/configure.host: Add libtool DLL options for Cygwin > and MinGW platforms. > > * libstdc++-v3/include/bits/c++config (_GLIBCXX_VISIBILITY_ATTR): On > platforms that don't support visibility, allow them to declare a macro > _GLIBCXX_PSEUDO_VISIBILITY that is applied in place of visibility. > (_GLIBCXX_PSEUDO_VISIBILITY): Supply empty default if not declared by > CPU- or OS-specific headers. > > * libstdc++-v3/config/os/newlib/os_defines.h > (_GLIBCXX_PSEUDO_VISIBILITY_default): New macro for dllimport. > (_GLIBCXX_PSEUDO_VISIBILITY_hidden): New empty macro. > (_GLIBCXX_PSEUDO_VISIBILITY): Evaluate to one of the above. > * libstdc++-v3/config/os/mingw32/os_defines.h > (_GLIBCXX_PSEUDO_VISIBILITY_default, > _GLIBCXX_PSEUDO_VISIBILITY_hidden, > _GLIBCXX_PSEUDO_VISIBILITY): Likewise. To be more precise here, there is still on part missing. It is treated at the moment handled as bug report for c++. The dllexport/dllexport attribute part should be done via namespace for libstdc++. This part is still missing. But by using auto-import, it already works for us pretty well. Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |