Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve configureless installation on debian and redhat machines #532

Merged
merged 4 commits into from
Sep 20, 2024

Conversation

JoshuaBehrens
Copy link
Contributor

Solves #522
Solves #529

This pull request shall allow debian/ubuntu installation to get this extension running quickly. I tested it using this script and empty OS installations:

apt update -yy && apt install -y build-essential git libv8-dev php php-dev
git clone https://github.com/JoshuaBehrens/v8js.git --branch feature/hassle-free-installation
cd v8js
phpize
./configure
make 
make test
make install
php -dextension=v8js -m

I tested this on Debian 12 on amd64 and arm64 Hetzner VMs with no further sources. So I was running [email protected] and v8@10. Debian 11 provides [email protected] out of the box and only ships v8@7 and does not run out of the box. Likely works with different php and v8 sources.

I tried it on CentOS 9 Stream on arm64 but there is a really bad support for arm binaries. I tried also on an amd64 machine and it is an installation hell. The v8-devel package depends on nodejs@16. There is a yum module for nodejs but only for nodejs 18, 20 and 22. AFAIK 18 would've be the matching one to v8@10 but v8-devel seems to be for the headers and library. Yikes!
I compiled v8 following your instructions in the Linux Readme. This is really helpful and sort of works. Eventually I got it running there but it is not handy on the first try:

yum install git php php-devel unzip curl
curl -L https://github.com/ninja-build/ninja/releases/download/v1.12.1/ninja-linux.zip -o ninja-linux.zip
unzip ninja-linux.zip
export PATH=`pwd`:$PATH

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH=`pwd`/depot_tools:"$PATH"
fetch v8
cd v8
git checkout 10.2.154.26
gclient sync

tools/dev/v8gen.py -vv x64.release -- is_component_build=true use_custom_libcxx=false
ninja -C out.gn/x64.release/

sudo mkdir -p /opt/v8/{lib,include}
sudo cp out.gn/x64.release/lib*.so out.gn/x64.release/*_blob.bin   out.gn/x64.release/icudtl.dat /opt/v8/lib/
sudo cp -R include/* /opt/v8/include/

cd $HOME

git clone https://github.com/JoshuaBehrens/v8js.git --branch feature/hassle-free-installation
cd v8js
phpize
./configure --with-v8js=/opt/v8/ CPPFLAGS="-DV8_COMPRESS_POINTERS"
make
make test
make install
php -dextension=v8js -m

I tried it on alpine but this seems to be a hassle-some story seeing Dockerfiles like this: https://github.com/modprobe/alpine-v8/blob/master/Dockerfile that need an interim debian layer for things to work.

I tried it on macOS 14/SDK 15 and installed v8 via homebrew but this is shipping v8 in version 12. This code is not yet ready for v8@12. I fixed some parts but this is a rabbit hole I am not yet ready to dig through. But I have a change for the config.m4, that understands to work with the filestructure in /opt/homebrew. So it might be a good additional change later, when I got v8@10 on macOS running.

So I tried to build a homebrew formula to build an old version of v8 as there was once a v8 formula compiling version 10 but it collides with the macOS SDK headers and the ones, that llvm ships. Really dumb one. I will try to work that one out because it is a shame, that there is only a "latest" formula. And I really need the macOS support.

@JoshuaBehrens
Copy link
Contributor Author

@stesie I tried to build a homebrew formula to get an installation of v8@10 and apparently this is not a release anymore, that neither receives features nor is part of the extended support. I queried this using this command:

$ curl -so - https://chromiumdash.appspot.com/fetch_releases\?platform\=Mac | jq '.|map(.hashes.v8)|unique|join("\n")' -r | xargs -n1 printf 'https://chromium.googlesource.com/v8/v8.git/+/%s\n' | xargs -n1 curl -so - | grep -oie 'version 1.*$' | sort -u
Version 12.6.228.21
Version 12.6.228.28
Version 12.6.228.30
Version 12.7.224.16
Version 12.8.374.1
Version 12.8.374.11
Version 12.8.374.21
Version 12.8.374.24
Version 12.8.374.26
Version 12.8.374.31
Version 12.8.374.33
Version 12.8.374.4
Version 12.8.374.7
Version 12.9.117
Version 12.9.191
Version 12.9.202.10
Version 12.9.202.16
Version 12.9.202.18
Version 12.9.202.3
Version 12.9.202.6
Version 12.9.73.1
Version 13.0.194
Version 13.0.244
Version 13.0.245
Version 13.0.245.1
Version 13.0.28
Version 13.0.66990160
Version 13.0.88
Version 13.1.19
Version 13.1.24
Version 13.1.29

With this in mind, should one push this library to support version 12 first?

@stesie stesie merged commit b447184 into phpv8:php8 Sep 20, 2024
@stesie
Copy link
Member

stesie commented Sep 20, 2024

@JoshuaBehrens once more, huge thank you for this contribution.
finally found some time to give it a try :-)

I think the script will have some issues, in case there are spaces in the directory name. But also the old code looks susceptible to that. So no worries. But in case you'd like to continue working on that, feel free 😄

That said, yes, I think the next goal for this project would be to make it work with recent versions of V8, i.e. 12.x and 13.x

and maybe we should also update the README files, telling that it's now also possible to use the libs that are shipped with Debian, Ubuntu, ...

So, once more, thank you !

@stesie
Copy link
Member

stesie commented Sep 20, 2024

hmmm, there seems to be a regression ...

given an Ubuntu 24.04 system, that has the lib installed in /usr ... and also manually compiled (like shown in the README.Linux.md file) in /opt

stesie@schlumpf:~/Projekte/v8js$ ./configure --with-v8js=/opt/v8-12.8.374.34 LDFLAGS="-lstdc++" CPPFLAGS="-DV8_COMPRESS_POINTERS"
...
checking for V8 files in default path... found in /opt/v8-12.8.374.34
found in /opt/v8-12.8.374.34
found in /usr

... the installation in /opt triggers the first and the third if successively. Then it finds the one in /usr ... so after all the one in /usr wins, even the user explicitly gave a different one.

IMHO we should override SEARCH_PATH="$PHP_V8JS" if it is given.

For which kind of installation/system is the first if block? can we maybe make it more explicit, by e.g. checking for a certain .h file, and not just assume stuff !?

and one more thing:

  case $host_os in
    darwin* )
      # MacOS does not support --rpath
      ;;
    * )
      LDFLAGS="$LDFLAGS -Wl,--rpath=$PHP_V8JS/$PHP_LIBDIR"
      ;;
  esac

... I think we should either evaluate this only if PHP_V8JS is actually set (so it matches what was present before) ... or we should also use it in the common path case ... but then probably use V8_LIBRARY_DIR variable instead.

However I think it doesn't make sense to do this in the "common path case", since the library loader should be configured to check these directories anyways.

@JoshuaBehrens JoshuaBehrens deleted the feature/hassle-free-installation branch September 23, 2024 06:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants