Build php 5.3 using docker

[glensc]

Implements the idea of moving build process to docker image:

• php/5.3.29/lib/libmemcached.so.11: file too short setup-php#358 (comment)

this way can develop this locally without needing an appropriate VM. and not even Linux (macOS).

The build can be performed locally with:

docker build . -f php-5.3/Dockerfile -t php-5.3

refs:

• ext-ldap fails to enable on 5.3 setup-php#386 (comment)
• a9a18a5

[glensc]

This is a dirty changeset to show how it could be done.

Ideally, the build flow should be optimized so that individual steps could be cached and executed in parallel. For example building PHP extensions do not need to be sequential but could be parallel build. A parallel build is offered by docker buildkit if stages have no dependencies.

[glensc]

By default, the build output is too long:

 => => # [output clipped, log limit 1MiB reached]

The log could be directed to a file, or limit disabled:

• [output clipped, log limit 1MiB reached] and then exit code 7 docker/buildx#484 (comment)

[shivammathur]

I had put this together in the little time I had yesterday, so the scripts surely can be polished.
Yes ideally different sapi, extensions and libraries which are compiled in the build can be moved to a parallel jobs and cached. If you have time this week or next, it would be great if you could work on improving this.

For docker I think you can use this action in a separate workflow in the CI to test the Dockerfile. It supports buildx and caching the layers.

[glensc]

If needing actions, I think this action is fancier:

• https://github.com/docker/setup-buildx-action

but currently, there's no such need, the docker build command works in the default setup.

[glensc]

Looks like GHA having temporary issues?

• https://github.com/glensc/php5-ubuntu/runs/1630834171?check_suite_focus=true

Run actions/checkout@v2
/usr/bin/docker exec  f517adb842589e0665ff8cd3e20dc78986a2eb4727add5179664d1c50dd9f81f sh -c "cat /etc/*release | grep ^ID"
/__e/node12/bin/node: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by /__e/node12/bin/node)
/__e/node12/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.16' not found (required by /__e/node12/bin/node)
/__e/node12/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by /__e/node12/bin/node)

this can't be my doing, as it fails before my jobs are executed, right?

[glensc]

or the failure is due to missing eglibc?

	&& curl -o /tmp/libc.deb -sL http://archive.ubuntu.com/ubuntu/pool/main/e/eglibc/libc6_2.19-0ubuntu6_amd64.deb \
	&& dpkg -i /tmp/libc.deb \

[shivammathur]

Nodejs build used in GitHub Action needs libstdc++6-4.7-dev and libc6_2.19 on ubuntu precise.

libstdc++6-4.7-dev can be sourced from this ppa ppa:ubuntu-toolchain-r/test

[glensc]

Argh, dropped the nodejs patching (5cb51df), it's no longer needed, it builds now:

• https://github.com/glensc/php5-ubuntu/runs/1630913895?check_suite_focus=true

can check after 20m, unless it fails sooner ;)

[glensc]

PLEASE do not force push, especially if PR is in WIP. I can't even figure out what your changes were to preserve them.

[glensc]

Noticed flaw in the current process: the built php53.tar is uploaded to the final filename before it's tested in CI.

[glensc]

@shivammathur here's build that passed (17m 23s):

• https://github.com/glensc/php5-ubuntu/runs/1638978933?check_suite_focus=true

it has no docker build optimization, everything is built serialized as before.

parallelization I planned to submit as separate PR after this is merged to keep the changes small and reviewable.

[shivammathur]

Sorry for the trouble, I have merged PR #2.
You can move the code to upload php53.tar.gz file to bintray after checks in the build53 workflow.

[glensc]

build result:

• https://github.com/glensc/php5-ubuntu/actions/runs/459826093
• https://github.com/glensc/php5-ubuntu/releases/tag/builds

removing WIP so you may merge if you wish.

[shivammathur]

@glensc Thanks for improving this. Great work!

[glensc]

IMHO this project should:

1. build 5.4, 5.5, 5.6 similar manner with php-build, in the end maybe all php versions?
2. build all external dependencies static, no shared libraries, this makes the php build relocatable, without dependencies like libicu.so, libssl.so. or keep the shared libs, but hardcode to /usr/local/php/lib.

this would provide a consistent process for all versions, currently, the workflow is really weird, really hard to grasp. some files committed to repo, some files built, some files downloaded. also, there's some weird tar+unpack+tar+unpack in the process which could be eliminated if things are straight forward. also, multiple compression formats for no apparent reasons. also build process does install steps (like enabling fpm service), sudo in places not needed, probably tons of leftovers from whatever the build was copied from.

I'm sure you're all aware of this and it takes time and efforts to improve this.

[shivammathur]

@glensc

I have thought about your suggestions and I agree that we also should build PHP 5.4 and PHP 5.5. Then we can incorporate patches for known bugs as well.

As for other PHP versions, I maintain php-builder. Currently it builds PHP 8.0 and master. May be I can add PHP 7.x builds there and PHP 5.6 build here once required (ppa:ondrej drops support for them).

Building already available libraries packages will add to maintenance and build time. So, better would be to keep shared libs and ship them with builds, and change the prefix of PHP to/usr as that would simplify scripts a lot as well. Not sure php-build supports different prefix and DESTDIR though. If not, this should be an easy patch upstream.

I would be able to give this time only next month or after. Before that, If you have time to implement this for PHP 5.4 and 5.5. I would be happy to test and merge.

[glensc]

@shivammathur I have been setting up the build for 5.5, I'll create WIP PR then for you to see. but I'm in the middle of splitting the job, so not everything is getting rebuilt if I change one file.

[glensc]

@shivammathur also, I think you should change your setup process from installing packages to enabling configs, i.e first the whole phpXY.tar is downloaded and unpacked, and then ini files are created or copied to enable extensions.

As I've noticed that versions that install .deb packages, are 3+ minutes long, but versions that use prebuilt php, take just seconds.

build time of base php images would not matter, as it's done only when there are fixes. and the docker cache layers will improve time if you want to develop things. for GHA docker image layers caching to work there's --cache-from option, but this requires publishing build result to docker registry, not sure this is wanted here.

See my similar project where all options are installed, but only enabling extensions with a simple script:

• https://gitlab.com/pld-linux/php#php-docker-images