[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Handle libgcc_s.so for glibc (Re: Definitions of INSTALL)
From:       "H . J . Lu" <hjl () lucon ! org>
Date:       2001-03-31 6:32:23
[Download RAW message or body]

On Sat, Mar 31, 2001 at 01:08:06AM +0100, Joseph S. Myers wrote:
> The toplevel Makefile.in hardcodes INSTALL to be the install-sh shell
> script, whereas gcc/Makefile.in uses @INSTALL@ detected by configure.  
> Why the difference?
> 
> Most of the time, gcc/Makefile.in's INSTALL then gets overridden by that
> passed down from the toplevel Makefile - except when used from within the
> stage submakes, to which INSTALL isn't passed.  These stage submakes build
> libgcc.mk, and hardcode the value of SHLIB_INSTALL in it.  This means that
> SHLIB_INSTALL - used to install the shared libgcc - uses the system
> install binary.  Whereas the shell script isn't safe for installing
> libgcc_s.so.0 (since it removes the target, then tries to use an mv binary
> that might be dynamically linked, possibly against libgcc), the install
> binary is more likely to be safe.

How do you know? /usr/bin/install on Linux MAY be linked against
libgcc_s.so.0.

> 
> Is this a deliberate clever design for arranging for the shared libgcc to
> be installed safely, or an accidental and fragile side effect of
> implementation that should be replaced by a safer mechanism for installing
> the shared libgcc while keeping its soname pointing to a valid library at
> all times?

Yes, we do that all the time with glibc. I have something to do it
right for glibc. Check out

http://ftp.kernel.org/pub/software/libs/glibc/hjl/libgcc-0.2.tar.gz

It is a glibc addon of libgcc with patches for glibc and gcc.


H.J.

[prev in list] [next in list] [prev in thread] [next in thread]