Unable to install on FreeBSD 11.0 p2
michaelbaisch opened this issue · 1 comments
The problem is building the libv8
gem. Specificly the version therubyracer depends on.
This installs the current version which is 5.3.332.38.3
and it works:
gem install libv8
But looking at the dependencies I have to install 3.16.14.17
which doesn't work:
› gem install libv8 -v 3.16.14.17
Building native extensions. This could take a while...
ERROR: Error installing libv8:
ERROR: Failed to build gem native extension.
current directory: /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/ext/libv8
/home/user/.rbenv/versions/2.3.3/bin/ruby -r ./siteconf20170215-65750-1esbefx.rb extconf.rb
creating Makefile
Applying /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/patches/do-not-use-vfp2.patch
Applying /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/patches/disable-building-tests.patch
Applying /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/patches/disable-werror-on-osx.patch
Applying /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/patches/do-not-imply-vfp3-and-armv7.patch
Applying /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/patches/fPIC-for-static.patch
Compiling v8 for x64
Using python 2.7.13
Using compiler: c++ (clang version 3.8.0)
Beginning compilation. This will take some time.
Building v8 with env CXX=c++ LINK=c++ /usr/local/bin/gmake x64.release ARFLAGS.target=crs werror=no
GYP_GENERATORS=make \
build/gyp/gyp --generator-output="out" build/all.gyp \
-Ibuild/standalone.gypi --depth=. \
-Dv8_target_arch=x64 \
-S.x64 -Dv8_enable_backtrace=1 -Dv8_can_use_vfp2_instructions=true -Darm_fpu=vfpv2 -Dv8_can_use_vfp3_instructions=true -Darm_fpu=vfpv3 -Dwerror=''
[...] ~50000 lines
../src/platform-freebsd.cc:371:53: error: use of undeclared identifier 'MAP_NORESERVE'
MAP_PRIVATE | MAP_ANON | MAP_NORESERVE,
^
../src/platform-freebsd.cc:443:48: error: use of undeclared identifier 'MAP_NORESERVE'
MAP_PRIVATE | MAP_ANON | MAP_NORESERVE,
^
../src/platform-freebsd.cc:473:40: error: use of undeclared identifier 'MAP_NORESERVE'
MAP_PRIVATE | MAP_ANON | MAP_NORESERVE | MAP_FIXED,
^
5 warnings and 3 errors generated.
gmake[1]: *** [tools/gyp/v8_base.target.x64.mk:219: /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/vendor/v8/out/x64.release/obj.target/v8_base/src/platform-freebsd.o] Error 1
gmake[1]: Leaving directory '/usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/vendor/v8/out'
gmake: *** [Makefile:195: x64.release] Error 2
/usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/ext/libv8/location.rb:36:in `block in verify_installation!': libv8 did not install properly, expected binary v8 archive '/usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/vendor/v8/out/x64.release/obj.target/tools/gyp/libv8_base.a'to exist, but it was not found (Libv8::Location::Vendor::ArchiveNotFound)
from /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/ext/libv8/location.rb:35:in `each'
from /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/ext/libv8/location.rb:35:in `verify_installation!'
from /usr/home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17/ext/libv8/location.rb:26:in `install!'
from extconf.rb:7:in `<main>'
extconf failed, exit code 1
Gem files will remain installed in /home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/libv8-3.16.14.17 for inspection.
Results logged to /home/user/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/extensions/x86_64-freebsd-11/2.3.0-static/libv8-3.16.14.17/gem_make.out
If I understand correctly this MAP_NORESERVE
flag got removed at some point from FreeBSD. So how do I build therubyracer?
Hello and thank you for the report!
This is an issue with the libv8
gem. I have opened a corresponding issue there. The correct course of action would be to investigate how did the upstream project get around this error and backport the patch, or submit a patch based on their solution to the libv8
gem.
At this time I cannot say when will I be able to tend to this myself so a contribution would be highly appreciated.