Bug 926425 – dev-lang/php-8.3.3 - [slibtool] installs libtool wrapper script instead of the php executable

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description orbea 2024-03-08 04:02:59 UTC]

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

[Comment 1 Michael Orlitzky 2024-03-09 12:09:44 UTC]

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?

[Comment 2 orbea 2024-03-09 16:05:02 UTC]

> 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

[Comment 3 Michael Orlitzky 2024-03-10 19:29:23 UTC]

(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!

[Comment 4 Michael Orlitzky 2024-03-11 01:21:06 UTC]

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 :(

[Comment 5 Michael Orlitzky 2024-03-11 15:01:26 UTC]

Reported upstream in $URL.

[Comment 6 orbea 2024-03-11 15:54:51 UTC]

> 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

[Comment 7 Michael Orlitzky 2024-06-11 19:39:11 UTC]

*** Bug 915314 has been marked as a duplicate of this bug. ***

[Comment 8 Michael Orlitzky 2024-06-11 19:39:38 UTC]

*** Bug 779496 has been marked as a duplicate of this bug. ***

[Comment 9 Michael Orlitzky 2024-06-11 19:40:15 UTC]

*** Bug 799611 has been marked as a duplicate of this bug. ***