The pc files for libxul and friends do not tell the build machinery that
it is out of the library search path. The technically correct fix is to
add '-rpath=${sdkdir}/lib' to the Libs: line, but this would break any
chance of upgrading libxul on a live system. Better is to symlink the
libs into /usr/lib as was done in the past. Andy, you've been doing all
the work there, what are your thoughts? I'm more partial to the symlink
method in that nothing would break on update (even though the -L flag is
not needed in the pc file at that point). Same thing would need to be
done if firefox, seamonkey, or thunderbird provide the only libxul.
dj [ /sources ]$ ldd /usr/lib64/libproxy.so
linux-vdso.so.1 => (0x00007fff2e5c7000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f26e65e7000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f26e63e3000)
libxul.so => not found
libxpcom.so => not found
libmozalloc.so => not found
libplds4.so => /usr/lib/libplds4.so (0x00007f26e61dd000)
libplc4.so => /usr/lib/libplc4.so (0x00007f26e5fd8000)
libnspr4.so => /usr/lib/libnspr4.so (0x00007f26e5d88000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f26e5a89000)
libm.so.6 => /lib/libm.so.6 (0x00007f26e5807000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f26e55f2000)
libc.so.6 => /lib/libc.so.6 (0x00007f26e5269000)
/lib64/ld-linux-x86-64.so.2 (0x00007f26e6a43000)
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
