[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: linking against c++ shared library built using autoconf (and libtool
Re: linking against c++ shared library built using autoconf (and libtool)
Thu, 15 Jul 2004 16:37:17 +0200
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
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).