PATCH: Handle the shared libgcc is a system library
H . J . Lu
hjl@lucon.org
Sun Jul 1 18:15:00 GMT 2001
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.
More information about the Libc-alpha
mailing list