Open orlitzky opened 8 months ago
I forgot to mention: to reproduce, install slibtool and then use make LIBTOOL=rlibtool
and make LIBTOOL=rlibtool install
to build/install PHP.
I think we can do that, yes. It's not exactly synced indeed. I'll check it out. Libtool install mode has some side effects in those .la text files and updates them a bit...
Hi! Just had my attention drawn to this, a couple of quick comments:
to properly handle recursive make, the command should actually be make LIBTOOL=rlibtool MAKE="make LIBTOOL=rlibtool"
using --mode=install rather than the non-[s]libtool install scripts is indeed the correct and right thing to do.
I hope that helps!
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 withLIBTOOL=rlibtool
, one such case arises: the following targets use$(LIBTOOL)
to build their dependencies, but then switch to$(INSTALL)
to install them: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 whenLIBTOOL=rlibtool
was used for the build. For example,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