This is the mail archive of the gcc-patches@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: 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


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