This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- To: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Subject: Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- From: Ulrich Drepper <drepper at redhat dot com>
- Date: 11 Jul 2000 00:51:24 -0700
- Cc: law at cygnus dot com, kettenis at wins dot uva dot nl, hjl at valinux dot com, rth at twiddle dot net, libc-hacker at sourceware dot cygnus dot com, gcc at gcc dot gnu dot org
- References: <3051.963286489@upchuck> <m366qdl2ar.fsf@otr.mynet.cygnus.com> <200007110721.JAA01138@loewis.home.cs.tu-berlin.de>
- Reply-To: drepper at cygnus dot com (Ulrich Drepper)
"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:
> Perhaps the target expert isn't too familiar with gcc sources. In that
> case, she can get help on gcc@gcc.gnu.org.
The problem is that this is causing much more pain than necessary.
Adding something to gcc is hard. There are so many things to take
care of since so many files are shared by many architecture.
Standaline packages don't have this problem.
> If his proposal was to provide a -fPIC libgcc object file collection
> which is transformed into a shared library during glibc installation -
> that won't work. I don't think users will want to rebuild glibc as
> part of gcc installation.
I don't think this works either. This is my I'm currently favouring a
standaline package. But there might be situation where a new libc
might require a new version of the libgcc.so and therefore there must
be some kind of coupling between this new package and glibc. Perhaps
something like an add-on (in the glibc-sense) which can also be used
standalone).