On Sat, 2012-12-29 at 15:01 -0700, Al Stone wrote:
> diff --git a/etc/ld.so.conf b/etc/ld.so.conf
> new file mode 100644
> index 0000000..4d778f0
> --- /dev/null
> +++ b/etc/ld.so.conf
> @@ -0,0 +1,2 @@
> +/lib64
> +/usr/lib64
>
> The linker should look in those directories anyway, but for some
reason
> it isn't.
Hrm. I'll look into this as I try to update the toolchain over
the next couple of weeks (I'd just like to bring it up-to-date
with upstream changes and Alexandre Oliva's work). I looked
into it a little bit and it appears /etc/ld.so.conf is created
by the %install step in the glibc spec file, which is not where
I would have expected it. I've forced it to be created by the
stage1 bootstrap script, for now.
/lib64 should have been built into the toolchain paths; I may
have missed an occurrence somewhere when I rebuilt it a couple
of weeks back. I'll double check as I update the sources; we
have a workaround for now.
I don't really think it is general library search paths which are
the problem. It is the case where the static linker needs to pull
in a library because of a DT_NEEDED tag in some other library it
pulled in. In this situation, I think the static linker tries to
act like the dynamic linker would wrt searching for the libraries.
So adding explicit -L/usr/lib64 doesn't help. /etc/ld.so.cache is
consulted for this special search so I used that as a workaround.
But /usr/lib64 should not need to be in /etc/ld.so.cache, so there
is probably some minor thing missing from the binutils sources or
in the configure command used to build it.