libgcc_s.so.1

jsmaby at virgo.umeche.maine.edu jsmaby at virgo.umeche.maine.edu
Sat Feb 8 02:46:48 PST 2003


I was playing around with deleting unused libraries, and noticed that
we don't have a libgcc_s.so.1 symbolic link in /usr/lib.  This means
that normally, ld won't be able to find it, so it will resort to the
static libgcc.a in /usr/lib/gcc-lib/....

This would be the reason that we aren't finding binaries dynamically
linked to it.  Since this is not the behavior desired by the gcc folks
(although I quite prefer it), I guess it's a pretty major lfs bug.

Note that the reason that c++ programs depend on it is that libstdc++.so.5
exists in /usr/lib, and since it was built by gcc, they correctly link
it against libgcc_s.so.1.

Note that I may be completely wrong, as libgcc_s != libgcc, so making
symbolic links in /usr/lib may not help at all.

If we are quite happy not having the extra runtime library dependancy,
we could configure gcc in chapter 6 with --disable-shared, which I
guess would get rid of the libstdc++ dependancy on it.

Of course, it's 5:30 in the morning here, and I'm still mostly asleep,
so this email may very well be completely incoherant.

-James Smaby
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list