Greg Schafer gschafer at
Sat Feb 8 03:53:01 PST 2003

On Sat, Feb 08, 2003 at 05:46:48AM -0500, jsmaby at wrote:
> I was playing around with deleting unused libraries, and noticed that
> we don't have a 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
> exists in /usr/lib, and since it was built by gcc, they correctly link
> it against
> 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
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list