Re: PATCH: Handle the shared libgcc is a system library

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

On Sun, Jul 01, 2001 at 10:50:17AM -0700, H . J . Lu wrote:
> This patch detects if there is a system shared libgcc in /lib or
> /usr/lib. If it detects one, the shared libgcc will be installed
> $(libsubdir) so that it won't override the system one by accident.
> 
> I also added --release/-dumprelease since I found --version couldn't
> tell the different releases of the same version. It can be used to
> install libgcc_s.so into /lib
> 
> # cp `gcc --print-file-name=libgcc_s.so.1` /lib/libgcc_s-`gcc --release`.so
> # ln -sf libgcc_s-`gcc --release`.so /lib/libgcc_s.so.1
> 
> so that there is always a libgcc_s.so.1 available at any time.


Some comments....

> +  if test "$build" = "$target"; then

$build = $target is not the right test.  I've built cross compilers
where $build = $target != $host.  Sure, it's perverse, but that's life,
and that's supported.

> +    # For systems where there is the shared libgcc in /lib or /usr/lib,
> +    # we assume it is a system library come from the system vendor, we
> +    # install our shared libgcc into $(libsubdir). We only check the
> +    # system shared libgcc for the native build.
> +    # FIXME: Need to check if the system shared libgcc library is
> +    #	     really ok.
> +    if test -e /lib/libgcc_s.so || test -e /usr/lib/libgcc_s.so; then
> +      slibdir='$(libsubdir)'
> +    fi

First of all, I think you want to check the version with the SONAME
here.  Installing a libgcc_s.so.2 someday, if for some reason that
should happen, shouldn't be affected.  Also, the .so link is often in a
development package while the .so.1 link is really a system library.

Second of all, this introduces a gratuitous random behavior that I
really don't like.  SOMETIMES gcc will install the library in /lib? 
And sometimes it won't?  Especially with:

> +  else
> +    # For the native compiler built by canadian cross build, we install
> +    # our shared libgcc into /lib if it is used as the system compiler.
> +    case $target in
> +    *-linux*)
> +      slibdir="/lib"
> +    ;;
> +    esac
> +  fi

So if I do a host-x-host cross, it'll automatically go into /lib, but
not otherwise?

And I regularly build compilers that are not meant to be installed on
the system that builds them.  Existance checks in /lib on the build
system are worse than useless here.  There's dozens of different build
systems that build from the same spec file.

And even worse, if you install libgcc_s in $(libsubdir), it will be
linked against but not found by the dynamic linker.  That's never going
to be the right solution.


If you really want to do automagic configuration based on the build
system, at least provide an option to cleanly ignore your magic. 
Something like --with-install-system-libgcc.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer