Build system installs libtool wrappers when using slibtool #13674

Description

slibtool is a reimplementation of GNU libtool in C. It's fairly mature; for example, plenty of Gentoo users build their entire systems with it.

One place where incompatibilities arise, however, is when the build system uses $LIBTOOL for part of the build/install process, but then switches to some other manual process that (unknowingly) depends on the internals of GNU libtool. When building PHP with LIBTOOL=rlibtool, one such case arises: the following targets use $(LIBTOOL) to build their dependencies, but then switch to $(INSTALL) to install them:

1. install-cli
2. install-fpm
3. install-phpdbg
4. install-cgi

With GNU libtool, the $(INSTALL) command does actually install the executable. slibtool however places its wrapper script in that location, placing the true executable in a .libs/ subdirectory instead. This leads to the wrapper scripts being installed when LIBTOOL=rlibtool was used for the build. For example,

$ head ~/tmp/php/usr/bin/php
#!/bin/sh
# libtool compatible executable wrapper
# Generated by rlibtool (slibtool 0.5.35)
# [commit reference: unknown]

if [ -z "$LD_LIBRARY_PATH" ]; then
	DL_PATH=
	COLON=
	LCOLON=
else

I think this can be fixed by using $(LIBTOOL) --mode=install $(INSTALL) rather than just $(INSTALL) to install these programs. It may also be more correct to install opcache and the libphp from the embed SAPI in the same manner, though nobody has complained about those not working yet.

PHP Version

git HEAD

Operating System

No response