El 12/03/11 16:48, Dimstar / Dominique Leuenberger escribió:
Hi,
We have libproxy in Factory, which uses cmake as it's toolchain. libproxy links against libmozjs, from xulrunner packages.
mozilla-js specified in its .pc file:
pkg-config --libs mozilla-js -Wl,-rpath,/usr/lib64/xulrunner-2.0 -L/usr/lib64/xulrunner-devel-2.0b12/lib -lmozjs -lplds4 -lplc4 -lnspr4 -lpthread -ldl
So it does give an rpath to be used. Apparently though, this does not make it through into the build shared object pacrunner_mozjs (libproxy1-pacrunner-mozjs).
There IS an rpath, but it points to /usr/lib64/xulrunner-devel-2.0b12/lib (the linking path of the lib).
Apparently this is the standard behavior of cmake.
But as you can imagine, this break with every smallest change in the xul packages (update to b13, b14... final) even though it should not (granted, sometimes/often it does, because the api/abi is not stable on libmozjs anyway).
Does somebody see a trick on how to convince cmake to use/add the proper rpath into the finally built shared object?
there is no sane trick against this crazy mozilla thing,other than rebuilding and republishing the package every time there is a version update. Mozilla products do not provide any sort of sanity in their build platform libraries, my only advice is to stay away from it if possible. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org