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: PATCH: Handle the shared libgcc is a system library


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.


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