This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)


   Date: Tue, 11 Jul 2000 10:00:49 -0700
   From: "H . J . Lu" <hjl@valinux.com>

   I don't think Linux has much choice. It probably has to be installed
   along side with libc.so.

It also might have to be installed whenever a new version of GCC is
installed.  In fact that's the only moment a new libgcc.so will have
to be installed apart from bootstrapping the whole scheme.

   >   > 
   >   > > what version # to use for libgcc,
   >   > 
   >   > This implies you are willing to track the version numbers for all the
   >   > different target.  Again, my argument is that you are *not* able to do
   >   > this accurately since you cannot effort spending that much time on it.
   > But we need to -- we're not just building a linux compiler.  We need this

   Look it this way. Since gcc is not a linux specific compiler and
   the libgcc/libc issuse is limited to very few targets, why should
   gcc spend HUGE amount of time up front and for continuing support?

In essence, the issues aren't really a libgcc/libc issue.  Currently
all ELF systems have similar problems with getting exceptions working
in the presence of shared libraries.  Most of the other systems with
shared libraries probably suffer too.

The fact that the Linux libc contains and reexports the frame info
registration functions make things a little more complicated, and
might induce the need for some additional tweaks.  But the problem
isn't Linux-specific by far.

Mark

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