Closed Bug 646375 Opened 9 years ago Closed 9 years ago
libxul links against wrong js lib if spidermonkey is installed when built with different options
Context: i have spidermonkey 2.0 installed on the system, built with default options (only --with-pthread --with-system-nspr --enable-readline). That means --enable-ctypes is _not_ set, and i have libjs_static.a + libmozjs.so in usr/local/lib. Firefox 4 configure script explicitely adds --enable-ctypes when calling configure in js/src, depending on the archs BUILD_CYPES is set to 1. In my case, MOZ_ENABLE_LIBXUL is set to 1 and MOZ_JS_LIBS gets set to MOZ_JS_STATIC_LIBS, which contains -L$(LIBXUL_DIST)/bin -ljs_static When linking libxul.so, it appears that libjs_static.a is picked from usr/local/lib and not from $(LIBXUL_DIST)/bin, which makes the build fail later on when linking xpcshell (missing syms to some of the ctypes functions in libjs) I've tried reordering EXTRA_DSO_LDOPTS in libxul-config.mk, but whatever i do there's still at least a -Wl,-rpath-link,/usr/local/lib before -L$(LIBXUL_DIST)/bin in the build line. So, to ensure that the correct libjs_static.a is picked i replaced $(MOZ_JS_LIBS) in libxul-config.mk:368 by ../../dist/bin/libjs_static.a, and libxul.so is correctly linked with the correct lib. Of course i can build systemwide spidermonkey with --enable-ctypes, but it shouldn't link against a lib we didn't explicitely plan to link with. Let me know if more information is needed to debug that issue.
I'm tempted to just say "don't do that" (installing a global spidermonkey lib), but I guess this should be more careful about what it's linking.
This should actually not be a problem any more since bug 584474 landed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to comment #1) > I'm tempted to just say "don't do that" (installing a global spidermonkey lib), Well, some third-party tools depend on spidermonkey being installed (mediatomb, couchdb, elinks to note some in openbsd's portstree) (In reply to comment #2) > This should actually not be a problem any more since bug 584474 landed. Sure, which nightly firefox src tarball can i test to see if it builds fine ?
(In reply to comment #3) > Sure, which nightly firefox src tarball can i test to see if it builds fine ? I don't think there are nightly source tarballs. You need to clone from mercurial.
You need to log in before you can comment on or make changes to this bug.