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