This is the mail archive of the
mailing list for the GCC project.
Re: libstdc++ libtool lossage
On Thu, Feb 21, 2002 at 05:30:51PM -0300, Alexandre Oliva wrote:
> On Feb 21, 2002, Richard Henderson <firstname.lastname@example.org> wrote:
> > gcc -shared # -lgcc
> > gcc -shared -shared-libgcc # -lgcc_s
> > g++ -shared # -lstdc++ -lgcc_s
> There's something I dislike very much about this design.
> Earlier, it was perfectly ok to use gcc to link multi-language
> applications and shared libraries, as long as the appropriate
> language-specific libraries were explicitly linked in.
True. The ideal solution is to examine all of the object files
to be included in the link and see if any exception handling
routines are needed, and make the decision based on that. I
couldn't figure out how to fit that into the gcc driver.
Right now, what'll happen is that if EH routines are needed,
but shared libgcc not used, they'll be seen as undefined symbols.
If you use -Wl,-z,defs then you get the proper error about this,
but unfortunately not otherwise.
> Since linking with -lgcc instead of -lgcc_s is an optimization (I
> suppose), wouldn't it be reasonable to use the safe construct by
> default (-lgcc_s), and the static libgcc only if explicitly requested
Given the number of C-only shared libraries on the typical linux
system, this is a relatively important optimization.
> ... but it appears to me that it would help all packages that
> build C++ shared libraries out there, especially those that use
And why wouldn't they be using g++ to link instead of gcc?
AFAICS, libstdc++ and libjava are special cases here.