This is the mail archive of the
mailing list for the GCC project.
Re: libstdc++ libtool lossage
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: aoliva at redhat dot com, gcc at gcc dot gnu dot org
- Date: Sun, 17 Feb 2002 10:48:56 -0500 (EST)
- Subject: Re: libstdc++ libtool lossage
On Sun, 17 Feb 2002, Richard Henderson wrote:
> The issue is that libstdc++.so is not being linked against
> libgcc_s.so, which means that the EH routines aren't being
> bound properly.
I'd guess this is an issue for libgcj as well.
> (1a) libstdc++.so is built with xgcc instead of g++,
But it is also built with --tag=CXX so libtool would try to do the right
thing, I suppose.
What baffles me is that libtool's CXX tag includes -nostdlib, so that even
if you managed to get -shared-libgcc in the command it would be ignored.
I don't understand this... using -nostdlib is just asking for trouble.
> (2a) xgcc isn't being given -shared-libgcc,
(I had thought it was decided long ago that -shared would imply
-shared-libgcc, or had I imagined it?)
As a workaround for libgcj I added -shared-libgcc to archive_cmds in
ltcf-c.sh. That seems to work fine. The trouble is that there are so
many cases of archive_cmds for different platforms, compilers, etc.
> There is no way it should be this difficult to build a stinking
> shared library.
Provided a GNU-ish system with glibc etc., it's really quite easy. That's
not why libtool exists...
> One of these days I'm going to make "gcc -shared"
> Just Work and then we can give libtool and automake the flush.
...it's getting better, "gcc -shared" only recently started working on
win32, for instance.
(What in heck does automake have to do with it?)