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