Arch Linux User Repository

Recommendations

1. Before installing this package, install depot-tools-git and follow its instructions.

2. To speed-up compilation, build on tmpfs and disable tests:

BUILDDIR=/tmp/makepkg makepkg --nocheck

Or using yay:

BUILDDIR=/tmp/makepkg yay -S --mflags --nocheck v8

@dflemstr

That's good news, I'll update the package next week.

Thanks

Correction: the new version of v8 I proposed does not have the libicu issue.

I'd like to see these patches applied: https://gist.github.com/dflemstr/2c06e81da38420d29e702c5bd3601afc

Should fix the build for many users, but the libicu issue might still exist.

Hi Thank you for the package, I am getting following error:

/usr/lib/v8/d8: symbol lookup error: /usr/lib/libv8.so: undefined symbol: _ZN6icu_618ByteSink5FlushEv

It seems like the v8 code has its own icu libraries used during compiling but these are not installed resulting in missing symbols.

Thank you.

I'd like to avoid compiling and get this as a pre-compiled package.

thx for the work, guys ;-)

@oneup Thanks for the info, I hope people will find it useful. This package is more of general layout than all-in-one solution due to the complexity of V8.

I'm having a hard time linking against libv8.so. It seems to be due to the fact the libc++.so is located at /usr/lib/v8/libc++.so. I assume that's to not conflict with an existing libc++.so? Unfortunately that makes it difficult both to link against and to dynamically load. Even if you set up pkg-config so that the linker is able to find /usr/lib/v8/libc++.so, you'll still be unable to run the executable because the loader won't know where to find it.

I think adding an RPATH of ${ORIGIN}/v8 to libv8.so would fix the problem, but good luck figuring out how to jam it in to the v8 build process.

For other people running into this issue, you can fix it for your own project by adding -Wl,-rpath,/usr/lib/v8 to your link command. But ideally the libv8.so library itself should know where to find libc++.so without other projects telling the linker/loader where to find it.

@MallardDuck Thanks for the tip, I used your idea. It should build fine now, also package updated to the latest 6.8 version.

Hey,

@ryanvade, @marcs, @znmeb, and anyone else with the building issues, I have a solution!

The root issue is that these scripts expect and depend on Python2 to build. Hence looking for the Python2 style urllib2. So in order to get this building right I simply did a local override; my local user's path has a ~/.bin and then I linked Python2 into that folder.

Once I did that things started working correctly for compiling. I'm gonna unlink it once the build is over, but this trick should work for others too. It's sorta documented in the Wiki: https://wiki.archlinux.org/index.php/python#Python_2 Start from: "Finally, you may not be able to control the script calls"

Hope that helps.