Upon testing the change itself I realized that it doesn't build properly
because
* the `pname` of a php extension is `php-<name>`, not `<name>`.
* calling the extension `openssl-legacy` resulted in PHP trying to compile
`ext/openssl-legacy` which broke since it doesn't exist:
source root is php-8.1.12
setting SOURCE_DATE_EPOCH to timestamp 1666719000 of file php-8.1.12/win32/wsyslog.c
patching sources
cdToExtensionRootPhase
/nix/store/48mnkga4kh84xyiqwzx8v7iv090i7z66-stdenv-linux/setup: line 1399: cd: ext/openssl-legacy: No such file or directory
I didn't encounter that one before because I was mostly interested in
having a sane behavior for everyone not using this "feature" and the
documentation around this. My findings about the behavior with turning
openssl1.1 on/off are still valid because I tested this on `master` with
manually replacing `openssl` by `openssl_1_1` in `php-packages.nix`.
To work around the issue I had to slightly modify the extension
build-system for PHP:
* The attribute `extensionName` is now relevant to determine the output
paths (e.g. `lib/openssl.so`). This is not a behavioral change for
existing extensions because then `extensionName==name`.
However when specifying `extName` in `php-packages.nix` this value is
overridden and it is made sure that the extension called `extName` NOT
`name` (i.e. `openssl` vs `openssl-legacy`) is built and installed.
The `name` still has to be kept to keep the legacy openssl available
as `php.extensions.openssl-legacy`.
Additionally I implemented a small VM test to check the behavior with
server-side encryption:
* For `stateVersion` below 22.11, OpenSSL 1.1 is used (in `basic.nix`
it's checked that OpenSSL 3 is used). With that the "default"
behavior of the module is checked.
* It is ensured that the PHP interpreter for Nextcloud's php-fpm
actually loads the correct openssl extension.
* It is tested that (encrypted) files remain usable when (temporarily)
installing OpenSSL3 (of course then they're not decryptable, but on a
rollback that should still be possible).
Finally, a few more documentation changes:
* I also mentioned the issue in `nextcloud.xml` to make sure the issue
is at least mentioned in the manual section about Nextcloud. Not too
much detail here, but the relevant option `enableBrokenCiphersForSSE`
is referenced.
* I fixed a few minor wording issues to also give the full context
(we're talking about Nextcloud; we're talking about the PHP extension
**only**; please check if you really need this even though it's
enabled by default).
This is because I felt that sometimes it might be hard to understand
what's going on when e.g. an eval-warning appears without telling where
exactly it comes from.
Building readline extension would say:
checking for libedit readline replacement... yes, shared
even when configuring `--without-libedit`. This is because `PHP_ARG_WITH(libedit, …)`, internally calls `PHP_ALWAYS_SHARED`, which in `phpize`-generated `configure.ac` is defined as always forcing the value to shared. This will prevent `PHP_ARG_WITH(readline, …)` from being invoked so `READLINE_DIR` variable will never be defined.
This was not an issue before we split the extension out of php.unwrapped in 282337799b, as `PHP_ALWAYS_SHARED` is empty there.
-----
Additionally, because the build script passed `-L$READLINE_DIR/lib` as a flag to the compiler on PHP < 7.4 (built by the nix-phps repository), this ended up with a FHS-like path being passed to the linker. And once we bumped GCC to 11 in 52f8cf58a4, the linker would fail:
gcc -shared .libs/readline.o .libs/readline_cli.o -Wl,--rpath -Wl,/lib -L/lib -ledit -lncurses -Wl,-soname -Wl,readline.so -o .libs/readline.so
impure path `/lib' used in link
collect2: error: ld returned 1 exit status
This no longer happens with PHP ≥ 7.4, since they switched to getting the linker flags from pkg-config in b537203d20.
----
As a compromise, let’s make the `PHP_ALWAYS_SHARED` function force `shared` status but only for flags that are not disabled. That will allow us to remove the libedit dependency and also the nasty patch for configure script due to `--with-libedit` not being passed (which would be required for PHP < 7.4 to be able to find readline.h from libedit).
Thanks to Pol Dellaiera for both bisections.
PHP obtained from Git contains files directly in the top-level directory,
which will be placed in Nix store. The generic builder will then copy it
to the /build sandbox as its basename with hash stripped (e.g. source/).
This breaks the assumption of `mkExtension`, which expects that PHP’s
source will be extracted into `php-«version»/` directory, since that
is what the release tarballs contain.
Let’s unset the `sourceRoot`, leaving it to `unpackPhase` to find
the source directory. Then, we will be able go to the extension
directory from there.
We use custom pre-configure phase so that both `postPatch` and
`preConfigure` is available to consumers.
PHP 7.3 won't be supported by upstream for the entire life cycle of
the 21.11 release.
Also drop the pcre' alias since it isn't needed anymore since we don't
need different pcre versions anymore.
The configure script checks whether iconv supports errno. Unfortunately, on PHP < 8, the test program includes $PHP_ICONV_H_PATH, which defaults to FHS path so it fails to build:
conftest.c:13:10: fatal error: /usr/include/iconv.h: No such file or directory
13 | #include </usr/include/iconv.h>
| ^~~~~~~~~~~~~~~~~~~~~~
That causes the feature check to report a false negative, leading PHP to use a degraded code that returns PHP_ICONV_ERR_UNKNOWN when error occurs, breaking granular error handling in applications.
To prevent this, let’s just include <iconv.h>.
PHP 8 just uses include path so the detection works there: 7bd1d70341
Passing list to `optional` wraps it in another list but we just want to return it as is.
Let’s just use `optionals` everywhere as that is much more predictable and makes such mistakes obvious.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This will make it easier to make overridable.
Had to rename `packages` attribute to `tools` in `php-packages.nix` because `packages` is shadowed by `makeScope`.
