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: law at redhat dot com
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: dje at watson dot ibm dot com (David Edelsohn), mark at codesourcery dot com, rth at redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Thu, 14 Feb 2002 13:44:25 -0700
- Subject: Re: Always link against static libgcc on hppa-linux
- Reply-to: law at redhat dot com
In message <200202142028.g1EKSQW2003183@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
> > I agree that these type of routines should be in the system C
> > library, not libgcc.a. The problem seems to be that the routines need to
> > be local requiring they be linked statically from an archive, not a shared
> > library. Glibc is a shared library, so I think it presents the same
> > problems as libgcc_s.so.
>
> Yes, the system C library is not the right place. These are really
> basic arithmetic routines needed by the compiler. I believe HP provided
> a separate library because it was used across different OS's and with
> different compilers. You are correct that they have to linked from
> an archive. I wouldn't even want to think of linking both shared and
> static C libraries.
So, why can't hppa-linux work like hppa-hpux in regards to the millicode
libraries?
hppa-hpux works by having the linker automatically include milli.a anytime
you link an object.
jeff