This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]