646375 - libxul links against wrong js lib if spidermonkey is installed when built with different options

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Landry Breuil (:gaston)]

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.

Comment 1

[(not currently active) Ted Mielczarek]

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.

Comment 2

[Mike Hommey [:glandium]]

This should actually not be a problem any more since bug 584474 landed.

Comment 3

[Landry Breuil (:gaston)]

(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 ?

Comment 4

[Mike Hommey [:glandium]]

(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.