On Mon, Sep 26, 2005 at 04:15:11PM +0000, Olly Betts wrote: > On 2005-09-23, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > [ By the way, I don't think everyone in this discussion has subscribed > > this list; if in doubt, speak up, or even better, set Mail-Followup-To: > > next time ] > > I'm following it on gmane, but an explicit Cc: isn't a problem. > > > * Jacob Meuser wrote on Fri, Sep 23, 2005 at 04:10:36AM CEST: > >> just add -lstdc++ manually. trust me, that works fine. I really don't > >> see why libtool should be adding this automatically. > > I did wonder about getting my project's configure to always specifying > "-lstdc++" if the compiler if GCC (with: test "$GXX" = yes). > > But I worry that I could end up trying to link in two incompatible > versions of libstdc++ on a machine with multiple GCC installations.
are you saying that on some platforms, you actually get -L/path/to -lstdc++? I don't think I've seen that one yet. certainly don't see that in the `g++ -shared -v' output you posted before. so how is libtool going to help with this? > I don't really want to risk breaking other platforms to get OpenBSD to > work, especially as I can document a workaround for OpenBSD users: > > make LDFLAGS=-lstdc++ > > I could write configure code to detect OpenBSD and add -lstdc++ for > OpenBSD. But such system specific tests are generally the wrong > approach - what if an older or newer version of OpenBSD behaves > differently? Writing a configure test which builds a C++ module and C > client and tries to dlopen the former from the latter would at least fix > this more generally, but wouldn't work when cross-compiling, and besides > seems a bit ridiculous when libtool is meant to hide shared library > portability issues. > > >> is it _always_ needed? what about -lsupc++? > > > > Ahh, very good question. Here we have an issue: it should be possible > > to _override_ the decision of libtool to add -lstdc++ on OpenBSD in all > > cases. But those cases, in my opinion, would be the exception rather > > than the rule: they are usually the cause when your package makes use of > > some system-specifics anyway. (Maybe there is even a way to detect > > whether supc++ is preferable over stdc++; I don't know of one, though, > > and in this case guessing is probably worse than allowing an override.) > > > > Can we agree on this somehow? What other issues, if any, are you > > experiencing? > > The obvious override mechanism is probably to see if the user specifies > "-lsupc++" explicitly and not to add -lstdc++ if they have. what I don't get, is that at one point, libtool assumes the linker knows what it's doing, and copies it. but then maybe what it's doing is not right? I think perhaps you should ask [EMAIL PROTECTED] about this. he might be able to explain why -lstdc++ is not implicitly used in `g++ -shared', which could give you a good starting point on how to "fix" the "problem". -- <[EMAIL PROTECTED]> _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
