Hello,
I'm working on updating the spidermonkey (the Mozilla project JavaScript
embeddable library) to the latest version and have come accross a serious
problem. If the library is to be compiled with thread safety it requires
linking against libnspr from the mozilla distribution. And that's where
problems begin - libnspr4.so is present in both mozilla and mozilla-snapshot
in, respectively, /usr/lib/mozilla and /usr/lib/mozilla-snapshot
directories. libnspr-dev contains no ar archive so static linking is out of
question. While it is easy to use pkg-config to link against any given
mozilla nspr, the resulting shared library (libsmjs.so) would require a
wrapper to pull the libnspr from the mozilla lib directory. Or it would
require using -rpath, or linking statically or putting in the respective
mozilla directory. All of those solutions are bad for various reasons:
- wrapper. Impossible to do with a shared library
- rpath. Against the policy.
- static linking. Impossible since there's no libnspr.a
- putting libsmjs in the mozilla lib dir. That makes the reason for
libsmjs existence rather invalid. The library is supposed to be used by
other libraries/binaries that should be able to pull it in from /usr/lib
At this moment I see no solution to the problem unless either of the
following is done:
- libnspr is moved to /usr/lib. Might be a problem because of mozilla vs.
mozilla-snapshot conflict.
- libnspr.a is added to libnspr-dev. Takuo, is it possible? Wouldn't that be
against the debian policy, too?
- /usr/lib/mozilla is added to the ld.so search path by default on debian
- an exception is made regarding the use of -rpath for cases like this.
I'm quite at loss about what to do, since I do want to provide thread
safety in the library. Any help will be greately appreciated,
thanks,
marek
Attachment:
pgp_r5n8u5WF0.pgp
Description: PGP signature