[SERVER-1764] rpath linking of libmozjs.so causes issues on Ubuntu Created: 09/Sep/10 Updated: 29/Feb/12 Resolved: 30/Aug/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | 1.4.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Clint Byrum | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Ubuntu |
||
| Attachments: |
|
| Operating System: | Linux |
| Participants: |
| Description |
|
This is a forwarding of the fix for this bug in Ubuntu https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/557024 In building 1.4.4 for Ubuntu Maverick, we've recently added a simple wrapper script that sets LD_LIBRARY_PATH to the current home of the system's xulrunner library. This is being done because the version of xulrunner changes quite often, breaking any programs that were built against the previous version with rpath embedded. It would make more sense to provide this wrapper with mongodb on Ubuntu systems than setting rpath. I do know that ultimately, what would make more sense would be a stable ABI in xulrunner and placement in /usr/lib, but for now that seems unlikely. Below is the wrapper script, which would most likely need to be customized with some variables from the build configuration to work properly. I've attached a patch to SConstruct and buildscripts/hacks_ubuntu.py that will remove the rpath and use LD_LIBRARY_PATH instead to run smoke tests. #!/bin/sh
|
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 30/Aug/11 ] |
|
as of 2.0.0-rc0, using a static sm included in source |
| Comment by Eliot Horowitz (Inactive) [ 12/Oct/10 ] |
|
So just to be clear about what we're planning on doing. Ok - now your comments above 1) In theory I agree with you 100% In practice, this is very hard. Using boost as an example. We currently support boost 1.33+. This is very hard for us as we have many forks in the code, and is problematic because we would like to use new features. Further, we have found bugs in certain versions (1.37) for example. So now, when you cross that with the number of distributions we need to support, it becomes quite complex. Many users run on centos for example which has old versions of boost that are unusable. So we have to have some sort of ability to statically link. 2) We will have an option to use system libraries when they work. If we can make mongo run great using all system libraries on ubuntu 10.10 for example, there is no reason we wont' do that. But that seems to be the exception and not the rule. 3) I'm all in favor of getting them to be more backwards compatible, but until that happens, we have to have a solution. Note we are considering moving away from spidermonkey/xulrunner because of this, which might make things simpler. So - we really do want to work with the library maintainers, its just proven to be very difficult. Maybe that's because we haven't had a great ubuntu/debian resource to work with. If you're up for it - let us know |
| Comment by Clint Byrum [ 12/Oct/10 ] |
|
Eliot, thank you for the enumeration of reasons behind this decision. I'd like to offer some counter points.
-On a side note, if you won't support releases compiled against system libraries, then your software will have to be moved to the 'multiverse' archive in Ubuntu (which many users do not enable, and which does not receive any support from the Ubuntu community)
I'm sure this bug report is not the right place to have this discussion, so I would appreciate it if you could forward it to the appropriate place, or inform me personally of where to go to discuss this further. |
| Comment by Eliot Horowitz (Inactive) [ 12/Oct/10 ] |
|
Our current plan is to statically link by default, and optionally use system libraries.
Now I don't mean fully static, i.e. pthread, libc, etc.. are still dynamic. but boost, pcre, spidermonkey will by default be not only static, but the source will be in the mongo repo so we can pin to versions, etc.. |
| Comment by Clint Byrum [ 10/Oct/10 ] |
|
I beg of you not to statically link, and to at least keep the default build method to the system libraries. Static linking means never knowing if your mongodb instance is vulnerable to security problems in underlying libraries. I don't think I have to remind anyone of the zlib problems of y'ore. With xulrunner's libmozjs.so already a bit of a mess and constantly releasing to solve security issues, statically linking would just be a nightmare. By using the system libraries, you give your sysadmins a fighting chance to secure their systems by upgrading vulnerable libraries. I do actually like the idea of splitting libmozjs.so into its own package: $ ldd /usr/lib/xulrunner-1.9.2.10/libmozjs.so Thats a very reasonable set of dependencies, no pango/cairo/etc. Please file a bug in Ubuntu requesting this. (The Developer Summit is coming up at the end of October, so now is a good time to start talking about changes like this). In fact even better would be to have the xulrunner upstream team agree to support this like a normal library (they currently do not guarantee ABI compatibility). But again, Please please please do not statically link or abandon the system libraries in the name of convenience at build time.. as it will just make things inconvenient and insecure later. |
| Comment by Eliot Horowitz (Inactive) [ 09/Oct/10 ] |
|
the build system is going to change to not use system libraries at all since they are too messy in general |
| Comment by Mark Renouf [ 09/Oct/10 ] |
|
Is it out of the question to simply fix the packaging so Mongo db is statically linked with libmozjs? This would eliminate an awfully long list of unecessary dependencies: i --\ xulrunner-1.9.2 1.9.2.10+b 1.9.2.10+b |