Re: postdeps empty on OpenBSD

[Olly Betts]

[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

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...

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.

> 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.

>> 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.

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.

Cheers,
    Olly