[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: postdeps empty on OpenBSD
From: |
Jacob Meuser |
Subject: |
Re: postdeps empty on OpenBSD |
Date: |
Mon, 26 Sep 2005 23:10:44 -0700 |
User-agent: |
Mutt/1.4.2i |
On Mon, Sep 26, 2005 at 04:15:11PM +0000, Olly Betts wrote:
> 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.
are you saying that on some platforms, you actually get
-L/path/to -lstdc++? 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?
> 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.
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?
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',
which could give you a good starting point on how to "fix" the
"problem".
--
<address@hidden>
- 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, 2005/09/26
- Re: postdeps empty on OpenBSD,
Jacob Meuser <=
- 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