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


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

Re: A libgcc patch for gcc 3.0


   Date: Fri, 23 Mar 2001 15:15:14 -0800
   From: "H . J . Lu" <hjl@lucon.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" <hjl@lucon.org>
   > 
   >    On Fri, Mar 23, 2001 at 11:01:14AM +0100, Mark Kettenis wrote:
   >    > "H . J . Lu" <hjl@lucon.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

   http://gcc.gnu.org/ml/gcc/2001-02/msg00485.html

There's nothing glibc-specific about this problem.

   http://gcc.gnu.org/ml/gcc/2001-02/msg00896.html

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
update.

   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.

Mark


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