Ken Moffat wrote: > Thanks, but my reading of the error message is that the failure > did indeed happen at link time. >
Really? I read it as a run-time error. config.log snippet: > 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 The compile/link stage exits with out errors config.log snippet: > 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 The error occurs after the program is run. The program complains that it cannot find the shared library. Also you mension that LD_LIBRARY_PATH works. My understanding was that LD_LIBRARY_PATH was only used at runtime to find libraries. > Using symlinks from /usr/lib is probably the least dangerous (if > you do them when you compile xulrunner, you know the version, and > are more likely to remember to update them when updating xulrunner). > Actually, I've a suspicion I got the idea from debian, who just move > a lot of libraries to /usr/lib. Sound's like the best idea to me. It's possible that this is a bug in the configure script or .pc file you mentioned as something needs to tell the dynamic linker to look outside the non-standard directories. > ĸen Thanks, Jack -- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
