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. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
