On 12/29/2012 03:26 PM, Mark Salter wrote:
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.
Ah. Yeah, probably true. I'll make sure to double check binutils.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@xxxxxxxxxx
-----------------------------------
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
