search

iusrepo / wishlist

meta repo for IUS new package requests
34 stars 8 forks source link

php56u-pecl-v8js-0.6.4 // php70u-pecl-v8js-1.3.3 #122

Closed mojo-iconrad closed 5 years ago

mojo-iconrad commented 7 years ago

What package do you want?

v8-5.3.337 (not sure about naming convention; devel packages as well) php56u-pecl-v8js-0.6.4 php70u-pecl-v8js-1.3.3

Why?

The v8 library as provided by the base RHEL/CentOS project in EL7 is version 3.14.5, which is incompatible with the php libraries for v8. The build process for updated versions of v8 is non-trivial on RHEL/CentOS/et.al. systems.

My own company as well as a few others I am in contact with the sysadmins for have resorted to using Docker containers in order to be able to provide this functionality. Having access to it as a pre-built package would be a huge improvement in our overall stability and environment.

OS versions

I am primarily concerned with having access to this package on EL7.

Testing

I agree to test the new package to ensure that it works as expected, and am willing to help coordinate to accomplish this.

carlwgeorge commented 7 years ago

Hello @mojo-iconrad, thanks for chatting with me in IRC. I'll look into how feasible this is and get back to you.

mojo-iconrad commented 7 years ago

I imagine something like "v8-5.3.337u" would work for the v8 package name.

b-harper commented 7 years ago

Hey @mojo-iconrad,

Sorry for the lack of updates to your request. Are you still interested in this package?

mojo-iconrad commented 7 years ago

I am, in fact. I've taken the liberty to dig up some prior work I was doing on getting this sort of thing to succeed. I'm not 100% certain this actually successfully executes all the way through but it is a damn sight closer than anything else I've found out in the wild: https://pastebin.com/GYXQU30h

b-harper commented 7 years ago

@mojo-iconrad,

Thanks for the update. Are you still needing both php56u and php70u?

mojo-iconrad commented 7 years ago

I personally am working w/ a constraint of being on 56u. But from what I gather it's actually easier to maintain the v8js extension for php70u.

b-harper commented 7 years ago

Typically, we build modules from stock versions for greater compatibility. Seeing that the pecl module requires V8 4.6.76+, that is not an option. EL7 provides V8 3.14.5.10. This does make the request a tad tricker. In the past, we have run into complications.

I'll start looking at creating updated V8 packages and take it from there.

mojo-iconrad commented 7 years ago

Seeing that the pecl module requires V8 4.6.76+, that is not an option.

That's why I provided the Dockerfile I pastebinned -- it's a successful compile process on el7 (The "official" v8 compile instructions don't successfully execute on CentOS/RHEL/Fedora). (Note: I just did some testing on that Dockerfile and I needed to remove the target="x64" line in order to get the compile to execute. This should not affect successful builds of libv8 itself.)

b-harper commented 7 years ago

Sorry, didn't mean to close this issue. Here is a request to get a newer (but new enough) version of V8 in EPEL7.

b-harper commented 7 years ago

As I start to looking through Fedora's V8 spec file, I have concerns if we should proceed with this request.

First of all, IUS stands for Inline Upsteam Stable. We typically build new packages when the upstream project releases a new version. The V8 project releases are tied to the releases of Chrome. There does not appear to be an easy way to tie a V8 branch/tag to a stable release of Chrome. We might just need to track when Fedora does a new release.

Also, the process to get the source tarball and other build requirements is very non-standard and is only getting stranger in the latest Fedora spec file.

I will keep poking and report back with my findings.

b-harper commented 7 years ago

Both Software Collections and CentOS Cloud SIG have V8, but only 3.14.

b-harper commented 7 years ago

After the the 3.x releases of V8, Fedora switched to clang. It would appear that EL7 does not have a new enough version of clang, as I have been running into errors about unknown clang options. I was able to bypass one by adding another change to %{optflags}. Then just ran into another one.

Your Dockerfile uses clang, but not the stock EL7 version. It downloads clang as part of the 'gclient sync' step (I think). As a packager, this raises concerns.

It would appear packaging a newer version of V8 for EL7 will require more resources than we currently have to allocate. While the classic 'pull requests welcome' still stands, we make no promises.

If EL7 gets a newer version of V8, we can look at creating the pecl modules.

mojo-iconrad commented 7 years ago

Yeah, I was just adapting the "official" build instructions for libv8 as minimally necessary to get it to successfully execute. They include the gclient sync task as part of it; I never dug too deeply into what it was doing under the hood.

b-harper commented 7 years ago

Developers tend to create instructions for the lowest common denominator, what is easiest and fastest for most platforms. Given their process is unique and seems overly complicated, I guess I shouldn't be surprised that they would use a bundled compiler.

After peering a bit into Chromium/V8 processes, I don't blame you for looking too closely.

carlwgeorge commented 5 years ago

Since PHP 5.6 and 7.0 are now EOL, I'm going to go ahead and close this out. Sorry we weren't able to come up with a solution to this one.