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

["H . J . Lu" <hjl at lucon dot org>]

On Sun, Jul 01, 2001 at 02:10:33PM -0700, Daniel Jacobowitz wrote:
> > 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.

That is a good point. I think it should check libgcc_s.so.1, not
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.

It is not always easy to do. I think /lib is an ok one for Linux.

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

I don't think it is a bad news. It happens all the time with
cross compiling. Also I have no idea what your libc.so.6 in
glibc 2.2 looks like when I send you my binary compiled against
my glibc 2.2. For all I know, you can have a link-time libc.so
with all the functions of the empty bodies. Neither the static
linker nor the dynamic linker will care.

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

It doesn't matter. The many features are detected by running
programss on the build machine.

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

You must have done something different. I have no problems with cross
compile, including weird ones like you described. On the other hand,
it was me who wrote those cross compile stuff in gcc. I guess I
know what I am doing :-).


H.J.