I'm trying to build epiphany against xulrunner (that is, using the
nss and nspr from within xulrunner). I've already symlinked nspr.pc
to mozilla-nspr.pc (for yelp, which apparently built fine with that
change), but now I'm starting to question if I'm merely overlooking
the obvious, or actually going senile.
If I do nothing, epiphany's configure reports that it cannot
compile and run XPCOM programs, and config.log shows libplds4.so is
not found.
This is in fact in /usr/lib/xulrunner-devel-1.9.0.6/lib along with
the other nspr libraries (and they are also hardlinked in sdk/lib).
(linewrapped:)
k...@bluesbreaker ~/epiphany-2.24.3 $ls -li
/usr/lib/xulrunner-devel-1.9.0.6/{,sdk/}lib/lib{plds,plc,nspr}4.so
183457 -rwxr-xr-x 1 root root 260734 2009-02-04 23:50
/usr/lib/xulrunner-devel-1.9.0.6/lib/libnspr4.so
183473 -rwxr-xr-x 1 root root 17678 2009-02-04 23:50
/usr/lib/xulrunner-devel-1.9.0.6/lib/libplc4.so
183466 -rwxr-xr-x 1 root root 12588 2009-02-04 23:50
/usr/lib/xulrunner-devel-1.9.0.6/lib/libplds4.so
183457 -rwxr-xr-x 1 root root 260734 2009-02-04 23:50
/usr/lib/xulrunner-devel-1.9.0.6/sdk/lib/libnspr4.so
183473 -rwxr-xr-x 1 root root 17678 2009-02-04 23:50
/usr/lib/xulrunner-devel-1.9.0.6/sdk/lib/libplc4.so
183466 -rwxr-xr-x 1 root root 12588 2009-02-04 23:50
/usr/lib/xulrunner-devel-1.9.0.6/sdk/lib/libplds4.so
The exact output is
configure:19946: checking whether we can compile and run XPCOM
programs
configure:20099: g++ -o conftest -g -O2 -fno-rtti -fshort-wchar
-DXPCOM_GLUE -fshort-wchar -I/usr/include/xulrunner-1.9.0.6/stable
-DXPCOM_GLUE -fshort-wchar -I/usr/include/xulrunner-1.9.0.6/unstable
-I/usr/include/xulrunner-1.9.0.6/stable -DXPCOM_GLUE -fshort-wchar
-DXPCOM_GLUE -fshort-wchar -I/usr/include/xulrunner-1.9.0.6/stable
-DXPCOM_GLUE -fshort-wchar -I/usr/include/xulrunner-1.9.0.6/unstable
-I/usr/include/xulrunner-1.9.0.6/stable
-I/usr/include/xulrunner-1.9.0.6/unstable conftest.cpp
-L/usr/lib/xulrunner-devel-1.9.0.6/lib -lxpcomglue -lplds4 -lplc4
-lnspr4 -lpthread -ldl -ldl >&5
configure:20102: $? = 0
configure:20108: ./conftest
./conftest: error while loading shared libraries: libplds4.so:
cannot open shared object file: No such file or directory
configure:20111: $? = 127
configure: program exited with status 127
Note that -L/usr/lib/xulrunner-devel-1.9.0.6/lib is being passed to
g++, but it still doesn't find the lib.
If I configure with
LD_LIBRARY_PATH=/usr/lib/xulrunner-devel-1.9.0.6/lib
configure is happy.
Similarly, if I set up symlinks for the nspr libs in /usr/lib,
configure is happy. In fact, that's what I did a few months ago
when I first hit this (before I moved on to separate nss, nspr to
get this to build on ppc), but I'm not happy using a workaround for
a problem I don't even understand!
The -L comes from the following line in the .pc file, but why isn't
it doing what I expect it to ?
Libs: -L${sdkdir}/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl
Strangely, if I pass LDFLAGS='-L/lib -L/usr/lib
-L/usr/lib/xulrunner-devel-1.9.0.6/lib' to configure (as if I was
building multilib with something misconfigured) it _doesn't_ find
this lib. Not that I'd want to use LDFLAGS, but they often work if
I need to apply some sticking plaster.
Clearly, using LD_LIBRARY_PATH in a script is asking for trouble
(this week 1.9.0.6, but I won't want that after the next version is
out), and putting it into /etc/ld.so.conf will lead to similar
problems. So, I'm looking for a solution which will work both for
my own scripts and for the book. Understanding what is going on here
would also be useful. Any pointers, please ?
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
