libtool
[Top][All Lists]
Advanced

[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: Mon, 26 Sep 2005 16:15:11 +0000 (UTC)
User-agent: slrn/0.9.8.1 (Linux)

On 2005-09-23, Ralf Wildenhues <address@hidden> 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.
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.

Cheers,
    Olly





reply via email to

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