This is the mail archive of the
mailing list for the glibc project.
Handle libgcc_s.so for glibc (Re: Definitions of INSTALL)
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Subject: Handle libgcc_s.so for glibc (Re: Definitions of INSTALL)
- From: "H . J . Lu" <hjl at lucon dot org>
- Date: Fri, 30 Mar 2001 22:32:23 -0800
- Cc: gcc at gcc dot gnu dot org, GNU C Library <libc-alpha at sourceware dot cygnus dot com>
- References: <Pine.LNX.firstname.lastname@example.org>
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
> 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
It is a glibc addon of libgcc with patches for glibc and gcc.