[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: |
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
- Re: postdeps empty on OpenBSD, (continued)
- Re: postdeps empty on OpenBSD, Ralf Wildenhues, 2005/09/22
- Re: postdeps empty on OpenBSD, Peter O'Gorman, 2005/09/22
- Re: postdeps empty on OpenBSD, Jacob Meuser, 2005/09/22
- Re: postdeps empty on OpenBSD, Peter O'Gorman, 2005/09/22
- Re: postdeps empty on OpenBSD, Jacob Meuser, 2005/09/22
- Re: postdeps empty on OpenBSD, Ralf Wildenhues, 2005/09/23
- Re: postdeps empty on OpenBSD,
Olly Betts <=
- Re: postdeps empty on OpenBSD, Jacob Meuser, 2005/09/27
- Re: postdeps empty on OpenBSD, Peter O'Gorman, 2005/09/27
- Re: postdeps empty on OpenBSD, Olly Betts, 2005/09/27
- Re: postdeps empty on OpenBSD, Jacob Meuser, 2005/09/28
- Re: postdeps empty on OpenBSD, Olly Betts, 2005/09/28
- Re: postdeps empty on OpenBSD, Peter O'Gorman, 2005/09/23
- Re: postdeps empty on OpenBSD, Olly Betts, 2005/09/26