#40247 closed defect (fixed)
mongodb @2.4.6 build error on v8 dependent code
| Reported by: | gutu@… | Owned by: | ryandesign (Ryan Carsten Schmidt) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.2.0 |
| Keywords: | Cc: | hapaguy (Brian Kurt Fujikawa), senseysensor, cooljeanius (Eric Gallager), Ruslan.Zakirov@…, twanvanderschoot (Twan van der Schoot), p.perroud@…, boloomka@… | |
| Port: | mongodb |
Description
It seems that the v8 installed (3.21) by macports is not compatible to what mongodb expects. After searching web I get impression that mongodb source ships with its own v8 that is currently only supported option when building mongodb.
Attachments (1)
Change History (24)
Changed 11 years ago by gutu@…
comment:1 Changed 11 years ago by gutu@…
For people googling this up, workaround is to modify the mongodb Portfile to build with Spidermonkey.
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/mongodb $ diff Portfile Portfile.original 64c64 < --usesm \ --- > --use-system-v8 \
comment:2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
| Owner: | changed from macports-tickets@… to ryandesign@… |
|---|---|
| Port: | mongodb added |
| Status: | new → assigned |
Thank you for reporting the problem, I can confirm it. The v8 port was updated to a newer version 24 hours ago (r110040) which is apparently not compatible with mongodb. I agree the fix is to use the internal version of v8 included with mongodb instead of the version provided by the v8 port.
However the fix you suggested is not correct, because the --usesm flag means "use SpiderMonkey". We don't want to use SpiderMonkey; we want to use v8.
comment:3 follow-up: 11 Changed 11 years ago by moderndeveloperllc (Mark Garrett)
Definitely don't want to use SpiderMonkey. Perhaps a variant to use internal vs. external libs? Would be useful in the future when this happens again.
comment:5 follow-up: 7 Changed 11 years ago by neverpanic (Clemens Lang)
Did anybody report this upstream? Maybe the mongodb people would consider updating their own copy of v8, fixing this problem without the need to duplicate the JS runtime env?
comment:6 Changed 11 years ago by neverpanic (Clemens Lang)
If your system is eligible for binary packages, you can also go the easy way of installing 3.17.15:
sudo port install http://packages.macports.org/v8/v8-3.17.6_0.darwin_12.x86_64.tbz2 # replace darwin_12 with the OS version appropriate for your system
If you recently upgraded from the older version of v8 you might even still have it installed and it might be sufficient to re-activate it:
sudo port activate v8 @3.17.6
comment:7 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to cal@…:
Did anybody report this upstream? Maybe the mongodb people would consider updating their own copy of v8, fixing this problem without the need to duplicate the JS runtime env?
https://jira.mongodb.org/browse/SERVER-10282
"compiling with versions of v8 other than what is included is not currently supported"
So I will modify the port to stop doing that and instead use the included version.
comment:11 follow-ups: 14 15 Changed 11 years ago by cooljeanius (Eric Gallager)
Replying to mark@…:
Definitely don't want to use SpiderMonkey.
Why not? Could this possibly be a variant?
comment:14 Changed 11 years ago by moderndeveloperllc (Mark Garrett)
Replying to egall@…:
Replying to mark@…:
Definitely don't want to use SpiderMonkey.
Why not? Could this possibly be a variant?
It would be a variant that would be difficult if not impossible to maintain now that mongodb has moved to V8. Considering that this ticket is because of a minor version bump in V8, trying to track how an entirely different engine integrates is beyond the scope of a project like macports. You might be able to get a specific build of SpiderMonkey to work with this version of mongodb, but any changes in either would probably break it. Might as well just compile it yourself so that the package manager doesn't break it for you in the future.
There are already a few good workarounds in this thread, and Ryan will change over the port soon enough.
comment:15 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to egall@…:
Replying to mark@…:
Definitely don't want to use SpiderMonkey.
Why not? Could this possibly be a variant?
I don't know of any reason why a user should care what JavaScript engine mongodb uses, therefore I don't intend to offer a variant. The user merely wants mongodb to have a working JavaScript engine. mongodb used to use spidermonkey, but recently switched the default to v8, therefore that's what I want the port to use, because I anticipate fewer problems relating to using a feature they no longer use by default.
comment:16 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | twan@… p.perroud@… added |
|---|
comment:18 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Fixed to use the internal copy of v8 in r110300. Run:
sudo port selfupdate
and then try installing or upgrading mongodb again.
There is a problem in the mongodb build system that I haven't looked into fixing yet that will make the build fail if MacPorts v8 is installed, so if you're building from source, deactivate v8 first:
sudo port -f deactivate v8
comment:20 Changed 11 years ago by neverpanic (Clemens Lang)
You should probably consider using the conflicts_build PortGroup to encode this fact in the Portfile.
comment:22 follow-up: 23 Changed 11 years ago by p.perroud@…
I confirm rebuilding mongodb after v8 was desactivated is *solving* the issue. Now - be aware that's mongo JS shell that's making use of v8 - not the database server itself. Meaning that v8 must be activated back after mongodb was rebuilt in order to interact with the database server from its shell. Good to know the issue was recorded but what about handling this issue on port install / upgrade calls? By example - when you update v8 you have to rebuild mongodb before or when you install mongodb you have to (re)install v8 later, etc...
comment:23 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to p.perroud@…:
I confirm rebuilding mongodb after v8 was desactivated is *solving* the issue. Now - be aware that's mongo JS shell that's making use of v8 - not the database server itself. Meaning that v8 must be activated back after mongodb was rebuilt in order to interact with the database server from its shell.
No, that's not necessary. The whole point of this ticket is that the v8 MacPorts provides is now too new for mongodb, therefore the solution was to make mongodb use its own internal version of v8 instead. MacPorts v8 is no longer involved -- except that having it activated while building mongodb causes mongodb to fail to build, therefore I advised how to deactivate it first. If you need MacPorts v8 for other reasons then you should reactivate it after building mongodb, but if you had only needed it for mongodb then you do not need to.
Good to know the issue was recorded but what about handling this issue on port install / upgrade calls?
It is handled automatically, in that if you have the v8 port active while trying to build mongodb, you will be told to deactivate it first, thanks to the conflicts_build portgroup.
By example - when you update v8 you have to rebuild mongodb before or when you install mongodb you have to (re)install v8 later, etc...
If it were necessary to rebuild a port, we would increase its revision, as for example I have done here with mongodb.
Build log