On Tue, Sep 27, 2005 at 01:31:37PM +0000, Olly Betts wrote: > [Cc:-ed to Mark Espie at Jacob's suggestion: > > 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' > > If you need context, this is the whole thread: > http://thread.gmane.org/gmane.comp.gnu.libtool.general/6671 > ] > > On 2005-09-27, Jacob Meuser <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 26, 2005 at 04:15:11PM +0000, Olly Betts wrote: > >> 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++? > > You certainly do in some cases. The one I've seen is with a private > build of GCC installed in a non-standard path (on Linux). Then I get > the following in dependency_libs in the .la file (amongst other things > I've pruned for clarity): > > -L/u1/olly/install/lib /u1/olly/install/lib/./libstdc++.la > /u1/olly/install/lib/./libstdc++.la
OK > I'm not sure why libstdc++.la is there twice... > > If I explicitly specify LDFLAGS=-lstdc++, then the explicit libstdc++ > appears before the -L above. So (for example) it would pull libstdc++ > from /usr/lib if there's one there... yes > I don't have access to the openbsd box right now to test, but I'd > imagine I'd get the exact same effect if I installed a private build of > GCC in my home directory on openbsd and used it. probably so > > 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? > > My point here is that I'm not happy with the suggested approach of > always explicitly linking with libstdc++. In some situations I believe > that will break builds which currently work by picking up the wrong > libstdc++ (or trying to link in two different copies of libstdc++). > > Even always explicitly linking with libstdc++ conditional on $host_os > matching openbsd* seems like it'll risk getting this wrong in some > cases (although at least only on a platform which doesn't work at > present anyway). > > So libtool could help by encapsulating the knowledge of when libstdc++ > needs to be explicitly specified. but how does libtool know that? > >> 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? > > Well, "not right" is perhaps a bit of a loaded phrase. But the current > openbsd linker's approach is problematic in the case here where I'm > linking a C++ module to be loaded via dlopen from a C program. The > linker doesn't add a dependency on libstdc++, and the C program doesn't > have a dependency on libstdc++ either, so the dlopen fails with > unresolved symbols. right. the module should be linked to libstdc++, not the program. and yes, on OpenBSD, you will not het this automatically, you must add it explicitly. > While this may seem like something of a corner case, many programs are > written in C and support loading of modules - python was the particular > case here, but most scripting languages support it (perl, php, etc). > So does apache, as another example. yes. I work with transcode (transcoding.org), which is a C program that loads modules. some modules are written in C++. it works on OpenBSD with the C++ modules linked to libstdc++. this is done unconditionally in the Makefile.ams with 'modfoo_la_LIBADD = -lstdc++'. I have not had a complaint about this method, but maybe no one's actually built such a module for transcode while using a non-system g++? -- <[EMAIL PROTECTED]> _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool