This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++ libtool lossage
On Feb 21, 2002, Richard Henderson <rth@redhat.com> wrote:
> 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.
How about arranging for -fexceptions (implied or not) to imply
-shared-libgcc (if a shared libgcc is available), and -fno-exceptions
(implied or not) to imply -static-libgcc?
This assumes EH support is the only reason for using a shared libgcc,
which I believe to be true.
>> ... but it appears to me that it would help all packages that
>> build C++ shared libraries out there, especially those that use
>> libtool.
> And why wouldn't they be using g++ to link instead of gcc?
If they're multi-language shared libraries, as I think I wrote in my
original message, using g++ is not always the right thing to do.
Still, your point about using g++ to link indeed invalidates my
concern about this change breaking all C++ libraries build with
libtool out there.
> AFAICS, libstdc++ and libjava are special cases here.
Indeed, they are. But not the only special cases.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer