Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#40247 closed defect (fixed)

mongodb @2.4.6 build error on v8 dependent code

Reported by: gutu@… Owned by: ryandesign (Ryan 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)

main.log (267.3 KB) - added by gutu@… 6 years ago.
Build log

Download all attachments as: .zip

Change History (24)

Changed 6 years ago by gutu@…

Attachment: main.log added

Build log

comment:1 Changed 6 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 6 years ago by ryandesign (Ryan Schmidt)

Owner: changed from macports-tickets@… to ryandesign@…
Port: mongodb added
Status: newassigned

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 Changed 6 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:4 Changed 6 years ago by bmhkim@…

I had success downgrading v8 to 3.17.15 in case someone cares for a way to get mongodb compiled using v8.

And just in case it's useful for anyone who finds this via search:

wiki:howto/InstallingOlderPort

and

svn co -r 109072 https://svn.macports.org/repository/macports/trunk/dports/lang/v8
Last edited 6 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:5 Changed 6 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 6 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 in reply to:  5 Changed 6 years ago by ryandesign (Ryan 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:8 Changed 6 years ago by moderndeveloperllc (Mark Garrett)

Cc: mark@… added

Cc Me!

comment:9 Changed 6 years ago by hapaguy (Brian Kurt Fujikawa)

Cc: brian.fujikawa@… added

Cc Me!

comment:10 Changed 6 years ago by senseysensor

Cc: mail_user_trash@… added

Cc Me!

comment:11 in reply to:  3 ; Changed 6 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:12 Changed 6 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:13 Changed 6 years ago by Ruslan.Zakirov@…

Cc: Ruslan.Zakirov@… added

Cc Me!

comment:14 in reply to:  11 Changed 6 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 in reply to:  11 Changed 6 years ago by ryandesign (Ryan 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 6 years ago by ryandesign (Ryan Schmidt)

Cc: twan@… p.perroud@… added

Has duplicates #40283, #40285.

comment:17 Changed 6 years ago by boloomka@…

Cc: boloomka@… added

Cc Me!

comment:18 Changed 6 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: assignedclosed

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:19 Changed 6 years ago by moderndeveloperllc (Mark Garrett)

Cc: mark@… removed

Cc Me!

comment:20 Changed 6 years ago by neverpanic (Clemens Lang)

You should probably consider using the conflicts_build PortGroup to encode this fact in the Portfile.

comment:21 Changed 6 years ago by ryandesign (Ryan Schmidt)

I already did.

comment:22 Changed 6 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 in reply to:  22 Changed 6 years ago by ryandesign (Ryan 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.

Note: See TracTickets for help on using tickets.