This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Always link against static libgcc on hppa-linux
- From: Mark Mitchell <mark at codesourcery dot com>
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: "dje at watson dot ibm dot com" <dje at watson dot ibm dot com>, "rth at redhat dot com" <rth at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 13 Feb 2002 18:54:36 -0800
- Subject: Re: Always link against static libgcc on hppa-linux
--On Wednesday, February 13, 2002 07:08:57 PM -0500 John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> 4. Now, we have a shared libgcc. On most platforms, one wants to
>> link with either the static libgcc, or the shared version, but
>> not both -- that can cause a variety of known EH problems, one
>> of which David seems to have (re)discovered. However, on
>> hppa-linux, if we don't link with the static libgcc, we are
>> missing the critical support routines.
>
> There currently are problems with unwinding on hppa-linux which I
> haven't been able to resolve yet. Just getting the frame note code
> working, is new. I thought that most of the EH issues were resolved
> when the routines got reorganized for gcc-3. I know previously that
> there were problems with a shared libstdc++ under hpux due to
> duplication of routines. If this is still a real problem, then I
> think a separate libmilli.a would be the best bet. I don't know
> enough about the gnu linker to have an informed opinion on the matter.
The point of the reorganization was to avoid the duplication of the
routines (and global data); that's why we don't want to link in
libgcc twice. I would not be at all surprised if (one) reason for
the EH failures was linking libgcc both statically and shared. Of
course, my crt*.o suggestion would avoid this problem without
requiring the creation of another library.
Still, if, for whatever reason, it's better to make libmilli.a, there's
no reason that shouldn't work -- it just seems more complicated to me.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com