Re: postdeps empty on OpenBSD

[Jacob Meuser]

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 address@hidden 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 <address@hidden> 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++?

-- 
<address@hidden>