When built with slibtool the resulting php package installs the libtool wrapper script instead of the php executable $ file /usr/lib64/php8.3/bin/php /usr/lib64/php8.3/bin/php: POSIX shell script, ASCII text executable This is because GNU libtool inconsistently places the executable in either the source directory or in the .libs/ sub-directory while slibtool always places it in the .libs/ directory and a wrapper script in the source directory. To this this it should install the executable with the $(LIBTOOL) command. Reproducible: Always
The PHP install process is pretty ugly due to our slotting. This is how "php" gets installed: local dest="${PHP_DESTDIR#${EPREFIX}}" into "${dest}" source="sapi/cli/php" dobin "${source}" local name="$(basename ${source})" dosym "..${dest#/usr}/bin/${name}" "/usr/bin/${name}${SLOT}" Would it be safe to e.g. check .libs/ first, and then fall back to the source directory?
> Would it be safe to e.g. check .libs/ first, and then fall back to the source directory? The ideal would to use an install target provided by the build system, but looking at their build system I am not sure if that is possible? Alternatively this works for me with both GNU libtool and slibtool, I think it would be better than checking the .libs directory first? name="$(basename ${source})" ${LIBTOOL:-./libtool} --mode=install cp "${source}" "${D}${dest}/bin/${name}" || die Also fwiw genkernel has this. https://github.com/gentoo/genkernel/blob/361810b23acd9452218368acecc7cc5262f00c74/gen_funcs.sh#L1988-L2009
(In reply to orbea from comment #2) > > Would it be safe to e.g. check .libs/ first, and then fall back to the source directory? > The ideal would to use an install target provided by the build system, but > looking at their build system I am not sure if that is possible? It's a PITA but I've been working on it... only to find that the upstream "install-cli" target (along with e.g. install-phpdbg) has the same problem!
And a new problem: after switching everything to the upstream install routines, I discovered that the apache module is being installed with, INSTALL_IT = ... apxs ... -i -a -n php libphp.la (source: Makefile) which breaks something with slibtool that isn't broken now :(
Reported upstream in $URL.
> And a new problem: after switching everything to the upstream install > routines, I discovered that the apache module is being installed with, This is a known issue in apxs that has been reported upstream, but without much attention. https://bz.apache.org/bugzilla/show_bug.cgi?id=66562
