Summary: | dev-db/couchdb / dev-lang/spidermonkey-1.8.2.x / net-libs/xulrunner-2.0 - couchjs segfaults | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tilo Prütz <tilo> |
Component: | New packages | Assignee: | Dirkjan Ochtman (RETIRED) <djc> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ssuominen |
Priority: | Normal | ||
Version: | 10.1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 361937 | ||
Bug Blocks: | |||
Attachments: | couchdb 1.1.0 patch for spidermonkey 1.8.5 |
Description
Tilo Prütz
2011-05-10 09:50:29 UTC
I forgot to mention, that I had seen bug 349660, bug 349824 and bug 349825 which seem similar. Mozilla team, any hints on how to select the correct libmozjs would be welcome. This issue would relate specifically to -L paths; I have a similar (but different) issue with xulrunner-1.9 and above and the system-wide expat. -I (and -L) override the default search path, ie, they are always used first. So, since libmozjs.so is found in -L/usr/lib/xulrunner-2.0 it will never be grabbed from /usr/lib/. The only way around this, afaik, is to position spidermonkey's libmozjs.so (or a simlink to it) in some other path, and then you can sort out the appropriate precedence to -L/path/to/spidermonkey/lib such that it is grabbed instead of xulrunner's. I haven't looked at this package in particular, but would it be possible to exclude it from using xulrunner at all? that would fix the issue too, more or less. It might be possible to patch ./configure (and maybe the makefiles) to get things to work cleaner, too; especially if bug 361937 gets applied and spidermonkey's lib flags can be read via pkg-config. ...AND it seems that I have an issue that's the converse of this one. When I compile a package that uses xulrunner-2 and spidermonkey-1.9 is not installed, it will grab libmozjs from xulrunner-2, but when i try and compile it when spidermonkey-1.9 *is* installed, then it grabs libmozjs from /usr/lib instead of from the -L path as specified via `pkg-config --libs mozilla-js`. Does /usr/lib , etc (the defaults) take precedence over paths specified by -L ? (googling didn't turn up an answer, although the gcc manpage seems to say that this is so, which means i was wrong in my previous comment) (In reply to comment #4) > ...AND it seems that I have an issue that's the converse of this one. When I > compile a package that uses xulrunner-2 and spidermonkey-1.9 is not installed, > it will grab libmozjs from xulrunner-2, but when i try and compile it when > spidermonkey-1.9 *is* installed, then it grabs libmozjs from /usr/lib instead > of from the -L path as specified via `pkg-config --libs mozilla-js`. > > Does /usr/lib , etc (the defaults) take precedence over paths specified by -L ? > (googling didn't turn up an answer, although the gcc manpage seems to say that > this is so, which means i was wrong in my previous comment) It depends on the order of the libraries which are passed to libtool during linking. We faced the same problem with dev-libs/gjs, and had to resort to build-time blockers on spidermonkey. This problem will go away once we add mozjs185[1], and when Firefox 5.0 goes stable, because xulrunner won't be needed, and mozjs185 has a pkgconfig file. 1. https://bugzilla.mozilla.org/show_bug.cgi?id=628723 PS: the spidermonkey version got downgraded to 1.8.2.x precisely for this reason, editing subject to reflect that It should be noted that this package will not build against spidermonkey-1.8.5 as it does not check for libmozjs185.so but just libmozjs.so .. so the dep should be updated to reflect this, ie, "<dev-lang/spidermonkey-1.8.5" for both ebuilds. Note that upstream does apparently have code (in configure.ac at least) to handle proper detection and usage of spidermonkey-1.8.5, so a version bump may be appropriate. --- Back to the original issue, I am not understanding why this error occurs. spidermonkey-1.8.2.* installs /usr/lib/libmozjs.so, and from what I can see in ./configure there is no reason why -L/usr/lib/xulrunner-* would be added to LDFLAGS and if that doesn't happen then this bug should never occur. Other packages (gjs, freewrl) are having the opposite issue -- package is built against xulrunner and the spidermonkey causes it to crash out. This package should not have this issue. # ldd /usr/lib64/couchdb/bin/couchjs: libmozjs.so => /usr/lib64/libmozjs.so (0xHEXHEXHEXHEX) AFAIK dev-db/couchdb does not support spidermonkey-1.8.5 in any released versions, and it might not even support it in 1.1.1, when that comes out. As mentioned in comment 5 the problem vanishes with spidermonkey 1.8.5 but one has to patch couchdb because it does not officially support spidermonkey 1.8.5 as mentioned in comment 7. Please find attached the couchdb (1.1.0) patch I am using for spidermonkey 1.8.5. Created attachment 289427 [details, diff]
couchdb 1.1.0 patch for spidermonkey 1.8.5
I've just bumped couchdb to 1.1.1, which should work with spidermonkey-1.8.5. Does that leave any issues on the table here? It would seem that, when 1.1.1 goes stable and/or xulrunner-2 is removed, then this bug would definitely be fixed. I am still wondering, though, if the original issue (xulrunner-2 conflicting with spidermonkey-1.8.2.15) is actually repeatable, since xulrunner-2's libs and such are separate from the default lib paths and as such should not be found. If my theory is correct then the whole bug should be close'able. removing blocker to spidermonkey-1.8.5 unmasking, since couchdb-1.1.1 works with it. I do not see anything needed by the mozilla team here, if you need us feel free to cc us back. Let's summarize: - net-libs/xulrunner was punted from tree wrt bug 403415 - couchdb-1.2.0 is in ~arch and works with ~arch spidermonkey 1.8.5 So nothing left to do here, right? Closing |