A program built on Linux does not start:
./main: error while loading shared libraries: libphpx.so:
cannot open shared object file: No such file or directory
libphpx.so sits beside the phpx checkout and libphp.so under the prefix the
libphp installer chose. The link line names both with -L, which tells the
linker where to look and the loader nothing, and neither directory is on the
default search path. The binary carries no RPATH or RUNPATH at all, so it
only runs under LD_LIBRARY_PATH.
Every part of the mechanism is already present and already reached on Linux.
NativeCommandOptionsTrait asks the platform for getDefaultRpaths() on every
non-nano build, and GccLikeBackend emits -Wl,-rpath for each entry it gets
back. Only the list is missing: PlatformBase returns an empty one, Macos
overrides it with the phpx and PHP library directories, and Linux never
overrode anything.
Move that override up to UnixPlatform, where Linux inherits it. The two
directories are the same ones the -L flags already name, each still guarded
by is_dir(), so macOS keeps the behavior it has today.
Android and Ios return an empty list on purpose: a path on the build host
means nothing on the device that runs the output. Wasi is a cross target too
and had been relying on the inherited default, so it states the same thing
explicitly rather than acquiring host paths from this move.
The recorded paths are absolute, matching what macOS has always emitted. That
is enough to run where the program was built, which is what an embed build
against a private PHP prefix can do in any case. Relocatable output needs
$ORIGIN and the libraries shipped alongside, or --full-static, and neither is
decided here.
Alexandre Gomes Gaigalas
b831dfacf8