libtool
[Top][All Lists]
Advanced

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




reply via email to

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