On Wed, 04 Apr 2012 00:23:14 +0100
DJ Lucas <[email protected]> wrote:
> 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 think we should remove xulrunner from the book;)
> 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)
I suspect you don't agree with my suggestion to remove it from the book ;)
so I'll make the changes tomorrow and put symlinks to the libraries
into /usr/lib.
Andy
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
