On 29-07-2012 16:14:12 -0500, Bob Friesenhahn wrote: > On Thu, 26 Jul 2012, Fabian Groffen wrote: > > > > Libtool apparently figures out what libs to link to by watching what the > > compiler does. It applies duplicate elimination on the result of that > > (don't know why) causing -lgcc_s -lc -lgcc_s to be turned into -lc > > -lgcc_s. As result, the library aborts on Solaris when it throws an > > exception because -lc comes before -lgcc_s. On Sparc, the result is > > -lgcc_s -lc, probably because both were double. > > > > I'm not sure this can be properly fixed by making sure -lgcc_s -lc > > remains, since GCC purposely emits the same library multiple times, so I > > decided to just disable the duplicate elimination for Solaris. > > Unfortunately, this fix is not working for me (not fixing issue I > already encountered). I do see libtool's exceptions test pass (for a > 32-bit build) , but it does not work for my own C++ application as a > 64-bit build. It seems that GCC itself is causing the harm (or is > just plain not working). With no specific request for any of these > libraries, this is the list of libraries that GCC 4.7.1 is passing to > collect2 while building my C++ test application: > > -lstdc++ -lm -lc -lgomp -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc
Can you be more specific here (e.g. post your compiler invocation line?) You have gomp and pthread in here, which IMO are not standard. I tried with GCC 4.6.3, but noticed that even though the link line is correct now, and collect2 also gets the right order, in some cases an executable still gets -lc -lgcc_s. That is, even if I run the link line manually, the linker (GNU binutils in my case) is reordering the input for my main executable at least. Fabian -- Fabian Groffen Gentoo on a different level
signature.asc
Description: Digital signature
