Compile your app into a single binary

[theofidry]

Feature Request

PHARs are a format that allows one to "compile" your application into a single file. Box also supports Docker to allow one to depend only on Docker and no longer on the PHP version installed on the machine.

An alternative to Docker could be to compile PHP statically with the necessary extensions. This way you would have two files:

• The PHAR
• The static PHP binary

Both could then be shipped in a self-extracting file. This also opens up the path to allow to package the application as a debian, ubuntu or OSX package without too much trouble.

The only known limitation would be if the application depends on a PHP extension that depends on a system library or extensions that cannot be compiled statically. Examples:

• Xdebug is a PHP extension that cannot be compiled statically
• ext-intl which depends on icu4c. If the link to the icu4c binary is hard-coded in the statically compiled extension, then the extension will work properly only on one machine

Resources:

• self extracting file
• PHP compilation:
  • https://github.com/phpbrew/phpbrew/blob/master/src/PhpBrew/Command/InstallCommand.php
  • https://github.com/phpbrew/phpbrew/blob/master/src/PhpBrew/Build.php
  • https://github.com/phpbrew/phpbrew/blob/master/src/PhpBrew/CommandBuilder.php

[MacFJA]

There is also http://virtphp.org/ which can pack a PHP version with extension etc.

[theofidry]

@MacFJA I'm having trouble to understand the difference with phpbrew tbh, but in any case good reference for another example on how to do it.

[MacFJA]

The big difference between virtPHP and PhpBrew (as far as I know) is the fact that virtPHP duplicate the existing (local) PHP version and add PECL, PEAR and composer to it, where PhpBrew build/compile a PHP from zero.

I did some test with virtPHP, and I don't this it can be used: some path in PECL and PEAR configuration are absolute and so can't work outside the installation path.

I also try PhpBrew, but it need a lots of system dev dependencies, I will try to run it inside of a Docker image

[theofidry]

Did you manage to get anywhere @MacFJA?

[MacFJA]

I made some tests with PhpBrew, I have the result: there are some absolute path inside the build PHP, so it won't work outsite the installation path.

Maybe I miss some configuration, but right now neither virtPHP nor PhpBrew can be used to make "fat binary"

I will take a look on AppImage, FlatPak, Snap and ZeroInstall to see if they can be used for this purpose

[theofidry]

there are some absolute path inside the build PHP

Do you have some examples? I thought it would be the case only for extensions having dependencies on your system applications

[theofidry]

I'm all for adding more shipping targets as well. Right now there is Docker but we can go further for sure

[theofidry]

Here's some thoughts after some discussions and hacking:

• clone https://github.com/php/php-src, it's easier and faster to switch between various branches than downloading the tar on the fly, at least to experiment
• call ./buildconf
• the next step is ./configure.

There is several flags to add (which are documented); for information you can also check php -i | grep "Configure Command" to see what your php binary has been built with.

The --static flag here is key and to bundle extensions with it, their appropriate --enable-extname=static flag should be called as well.

• call make smth (smth is one of the command available, need to check which one - definitely not install!)

To include third-party extensions, i.e. the ones not provided by php-src, their source code need to be moved to under the php-src ext directory (like the extensions already present there). This step needs to be done before calling ./buildconf.

The output of this should be the PHP static binary as well as .a files. Now the PHP static binary may not ship some requirements from the system (to see this, use otool -L my-bin. There is two ways to go from there:

• Explicitly document those and expect the user to install those requirements beforehand
• Go one step further (more on this bellow).

To avoid having the user to install those requirements which can be tricky, it should be possible to get those system libraries in .a files as well. Once done, it's possible to assemble all the .a into the final PHP binary again, which will time will include the system libraries.

It is also worth mentioning that there is likely the following points to be aware of:

• When compiling the PHP binary, the "default" flags shouldn't be taken: you don't want the binary to include CGI, FPM & sessions for example since it's for a CLI application
• Some extensions cannot be compiled statically (e.g. xdebug although this peculiar case should not be an issue)
• Most applications don't document correctly their extension dependencies. It's often the case for exoteric dependencies but much less for the ones traditionally included in the core. For example most applications don't declare their dependency on ext-json despite using json_(de)encode(). Recommending a tool and encouraging its usage will be necessary here

Once all of this is done, there is still the question of how to package the app itself for which there is likely multiple alternatives depending of the platform or other. Maybe one way would be to create a C application which ships both the PHAR and the static binary and manages to do the call, to effectively distribute a single, dependency free, binary file.

Ah, there is also the question of licenses for both extensions and system libraries.

[wesmontgomery]

@theofidry are you and @mpociot collaborating on this? 👀

https://twitter.com/marcelpociot/status/1498244220620099588

[theofidry]

I would love to see some work done here, but no I did not get more details regarding the experiment neither can I see an attempt to try to add it to laravel zero. I don't know if the experiment was just not conclusive or if @mpociot switched to something else.