[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

libnspr and libraries in /usr/lib that require it


  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,



Attachment: pgpZ9jfIb9ppp.pgp
Description: PGP signature

Reply to: