Optional GNU C Library support

[dunglas]

Currently, Musl is used, but there are many known issues with Musl. Would it be possible to add a flag to use the static glibc instead of Musl?

[dunglas]

Alternatively, we may try to link everything statically except libc, which is part of POSIX anyway and should always be available: https://stackoverflow.com/a/58565307/1352334

This seems to be called "mostly-static linking": https://docs.oracle.com/en/graalvm/jdk/17/docs/reference-manual/native-image/guides/build-static-executables/#build-a-statically-linked-or-mostly-statically-linked-native-executable

[crazywhalecc]

Would it be possible to add a flag to use the static glibc instead of Musl?

This is a complex issue. To sum up, the reasons why we use musl by default are as follows:

1. musl-libc is simpler and smaller than glibc, and is especially suitable for static compilation. And thanks to @DubbleClick's musl-cross-make, we can compile musl-static binary on glibc-based distros (same as alpine).
2. Pure static linking of glibc is not recommended, see stackoverflow.
3. If we just use dynamic linking glibc as default ("mostly-static linking), we cannot run php binary on alpine and musl-based OS, and of course we will not be able to compile static-php-cli on alpine with this method.

If you want to dig deeper:

1. we already have discussion about standalone (not purely static) php cli but nobody comments about this :(
2. We can just set --cc or --cxx to change the glibc-based gcc now, but I haven't made a simple flag to enable this feature. I tested this feature but "not the most portable" problem beats me.

[crazywhalecc]

To put it jokingly, the existence of this project is also due to the confusion of Linux libc and the fact that most early projects did not like static compilation. It would be better if Linux has default library and it provides all possibilities(dynamic and static) and is stable. LinuxBuilder is also more complex than MacOSBuilder and WindowsBuilder.

[henderkes]

Just as an addition to the listed problems (espevially static glibc linking still requiring dynamic libraries, so what's even the point):

I've dabbled in dynamic linking with glibc before and ran into huge issues with different distros. It would be a lot of work to keep it working and stable for them all. There would be an advantage, mainly loading of dynamic extensions on glibc systems, but it also eliminates a major benefit of the project (compile it once, use it anywhere).

[crazywhalecc]

After #403 merged, I can make a set of env variables for building glibc version of static-php. But we also need --skip-item for docker command, patch cmake toolchain file and disable injection for musl tools. These will be added as minor version updates after the 2.2 release.

[dkarlovi]

In the meantime, I've opened https://github.com/php/php-src/issues/13877 which got some traction already:

https://github.com/php/php-src/pull/13925 https://github.com/php/php-src/pull/13974

It's possible PHP's musl support will get substantially better over time.

[crazywhalecc]

@dunglas Today I evaluated the possibility of linking static-php using glibc. Unfortunately, doing so comes at a huge loss of portability.

The main problem is not compilation, but the version of glibc. Because if we do not restrict compilation on a specific distro, the compiled static-php may require a newer glibc version, which cannot be used for older versions of the distro. A very simple example is: the results built on Debian11 cannot be used on Debian10. The result is similar to many closed source software: different binaries for each major version.

# ldd buildroot/bin/php
buildroot/bin/php: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by buildroot/bin/php)
buildroot/bin/php: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by buildroot/bin/php)
buildroot/bin/php: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by buildroot/bin/php)
buildroot/bin/php: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by buildroot/bin/php)
buildroot/bin/php: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by buildroot/bin/php)
	linux-vdso.so.1 (0x00007fff69df6000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fad15277000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fad14ed9000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fad14cc1000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fad148d0000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fad17fab000)

[dunglas]

Thank you very much for working on this. I agree that it's a big limitation. Let's close this issue then?

[crazywhalecc]

I will write the compilation variables based on glibc on doc or blog later, but obviously this will not become official support. Let's close this.

[crazywhalecc]

@dunglas An interesting thing you may want to know: I only need to build Docker for a specific old glibc environment (e.g. CentOS 7 with an old toolchain, this is using glibc 2.17 as minimal glibc version), and with a patched env.ini and workarounds for some special libraries, I can build a static binary with dynamically linked glibc and have it work on almost all Linux distros (except Alpine Linux).

This may be an optional feature, as musl-libc does have a lot of issues that cannot be solved directly (I also encountered some problems with musl recently). It is true that this work may not be done as a default target, but the it shows that SPC is capable of building another results.

If you or anyone are interested, I can reopen this issue and related pr in the future.

[SerafimArts]

If you or anyone are interested, I can reopen this issue and related pr in the future.

Adding FFI support - solves a huge number of problems, as it provides direct access to the system.

If we exaggerate a little, then the presence of this extension makes all other extensions for PHP unnecessary, as you can write them yourself if you wish (lol).

So personally, I am interested in this issue.

[dunglas]

This would help a lot FrankenPHP, I'm definitely interested!