libgcc_s.so.1

Greg Schafer gschafer at zip.com.au
Sat Feb 8 03:53:01 PST 2003


On Sat, Feb 08, 2003 at 05:46:48AM -0500, jsmaby at virgo.umeche.maine.edu wrote:
> 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/....

Bzzt. You obviously haven't been reading the pure LFS stuff and thus learned
all about linker scripts and their search paths :-)  ld looks in /lib as
well as /usr/lib. Check the ldscripts and see for yourself.

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

No. This only came up 3 days ago! Definitely not paying attention! :-)

Read my posts in the thread that starts here:-

http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2003/02/0094.html

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

I wish folk would actually *test* stuff before making wild suggestions like
this...

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

:-)

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