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 01:40:16PM -0700, H . J . Lu wrote:
> 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.

Sorry.  That's what I get for not looking at the surrounding hundred
lines of context.

> > > +    # 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.

Read the rest of the paragraph.  The .so link may not be installed,
even if the system libgcc is.

> > > +  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.

Certainly.  But it should be the same packaging that you have to do for
a native build on the $host=$target system, whenever possible.

> > 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're going to take this stance, why install it at all?  The one in
$(libsubdir) will be found at link time but not at run time, which is
bad news.  If you want the system copy to be found at run time, find it
at link time also.

> > 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.

Huh?  Of course.  I specify host and target quite explicitly. 
Sometimes, I build native ($host=$target) compilers for our embedded
x86 platforms on an x68 Debian host.  I don't want it picking up
anything about the build machine, and while it's a losing fight I'm
keeping up the effort.  It's especially challenging because programs
built by the "cross compiler" will run on the build system, and keeping
autoconf in the right frame of mind is hard enough.  But $build !=
$host.

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


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