autoconf
[Top][All Lists]
Advanced

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

Re: linking against c++ shared library built using autoconf (and libtool


From: Ludovic Courtès
Subject: Re: linking against c++ shared library built using autoconf (and libtool)
Date: Thu, 15 Jul 2004 16:37:17 +0200
User-agent: Mutt/1.5.4i [Guile enabled]

Today, 26 minutes, 47 seconds ago, Ralf Corsepius wrote:
> No, I am referring to libstdc++. libstdc++ is an internal implementation
> detail of g++ you should not have to care about.
> 
> However "presence of libstdc++" is not the actual problem, here. The
> actual problem is "using g++ to link" means more than adding "-lstdc++"
> to LDFLAGS. For example, on some targets w/ some gcc-versions it means
> adding further libs (e.g. libsupc++), composing ctors/dtors,  pulling in
> alternative startup code etc.
> 
> What it actually does highly depends on the gcc-version you are using
> and the target (architecture, OS, object format etc.) you are compiling
> for.

All of libstdc++'s dependencies is likely to be described in Libtool's
"libstdc++.la" file so something like "libtool --mode=link gcc -o foo
-lstdc++" should to the trick, right?

> This would be very hard. You'd have to design your  library in such a
> way that it does not have any unresolved C++ symbol.
> 
> In practice, this would mean to avoid  using the STL and to avoid most
> features that make C++ attractive (no static constructors, no iostreams
> etc.). Furthermore, you'd have to set up your CXX-flags in such a way
> that it does not generate C++ symbols (type-info, exceptions).

Even if you link with libstdc++ and its dependencies?  From my
understanding, STL code (besides inlines) resides in libstdc++ while
runtime support for RTTI, static ctors and other language features are
implemented in libsupc++ (section 2.5 of the FAQ).

Thanks,
Ludovic.




reply via email to

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