[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: postdeps empty on OpenBSD

From: Olly Betts
Subject: Re: postdeps empty on OpenBSD
Date: Tue, 27 Sep 2005 13:31:37 +0000 (UTC)
User-agent: slrn/ (Linux)

[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:

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

I'm not sure why 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]