PATCH: Handle the shared libgcc is a system library
H . J . Lu
hjl@lucon.org
Sun Jul 1 13:40:00 GMT 2001
On Sun, Jul 01, 2001 at 12:33:57PM -0700, Daniel Jacobowitz wrote:
> 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.
A few lines above, there is
elif test "$host" != "$target"; then
slibdir='$(build_tooldir)/lib'
else
slibdir='$(libdir)'
if test "$build" = "$target"; then
At this point, $host = $target. When $build = $target != $host, you
are building a cross compiler, slibdir is set to $(build_tooldir)/lib.
>
> > + # 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
SONAME only exists in ELF. the gcc developers have promised that
libgcc_s.so.1 will be here to stay. If there is a libgcc_s.so.2,
we may have a bigger problem than where libgcc_s.so.2 should be
installed.
>
> > + 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?
It won't automatically go anywhere. I don't think many people will do
# make install
for a canadian cross build. The possible usage is
# make install prefix=/var/tmp/gcc
# rm -f /var/tmp/gcc/lib/libgcc_s.so
# ln -s ../../lib/libgcc_s.so.1 /var/tmp/gcc/usr/lib/libgcc_s.so
In any case, you have to do some packaging than
# make install
for a canadian cross build.
>
> 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.
Well, it can be called cross build. It is handled differently.
>
> 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.
>
Why? It only gets installed in $(libsubdir) if there is a system
shared libgcc.
>
> 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.
I am not sure if gcc is ever designed for such a thing. When you do
# ./configure
# make bootstrap
# make install
it assumes $build = $host = $target. If you want to do those 3 steps on
different machines, It may not work right since ./configure may detect
somethings which don't exist or aren't true on other machines. You are
better off with cross compile.
H.J.
More information about the Libc-alpha
mailing list