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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
