This is the mail archive of the
mailing list for the glibc project.
Re: A libgcc patch for gcc 3.0
Date: Fri, 23 Mar 2001 15:15:14 -0800
From: "H . J . Lu" <firstname.lastname@example.org>
On Sat, Mar 24, 2001 at 12:10:03AM +0100, Mark Kettenis wrote:
> Date: Fri, 23 Mar 2001 08:26:35 -0800
> From: "H . J . Lu" <email@example.com>
> On Fri, Mar 23, 2001 at 11:01:14AM +0100, Mark Kettenis wrote:
> > "H . J . Lu" <firstname.lastname@example.org> writes:
> > > I am not sure if gcc 3.0 will do the right thing for glibc. Here is
> > > a patch. Basiscally, we treat libgcc_s.so as a system library. gcc
> > > will use libgcc_s.so only if it is available from system or gcc is
> > > configured with
> > >
> > > --enable-shared=libgcc/--enable-shared=gcc
> > >
> > > Any comments?
> > 1. If you're "not sure if gcc 3.0 will do the right thing for glibc"
> > it would be a good idea to:
> > 1. Check if it really doesn't.
> > 2. Identify what's going wrong. And try to explain it to the rest
> > of us.
> > 3. Try to come up with a fix.
> > Jumping straight to step 3 really isn't a good idea.
> I have done 1 and 2.
> And would you care to share your knowledge with the rest of us?
Please check the gcc/glibc mailing list archives. There are many
threads on this topic. Here are a few
There's nothing glibc-specific about this problem.
Again nothing glibc-specific about it. Yes, things start to get messy
when multiple shared libgcc's are installed, especially when people
start messing with -R/-rpath and/or LD_LIBRARY_PATH. But I fail to
understand how your patch is going to solve that in a reliable way.
Not installing a shared libgcc if one has been found in /lib indeed
does avoid increasing the number of installed libgcc's under some
circumstances, but also might deprive people of a necessary libgcc
I don't want to spend any more time discussing why it is bad for glibc.
So be it. And expect everybody else to ignore you. You're not going
to get any patches integrated into GCC if you keep this attitude.