Bug 201193 - Mk/Uses/php.mk setting incorrect PHP_EXT_DIR
Summary: Mk/Uses/php.mk setting incorrect PHP_EXT_DIR
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Alex Dupre
URL:
Keywords:
: 214979 218304 226615 227762 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-06-29 09:25 UTC by Bernard Spil
Modified: 2019-07-03 01:25 UTC (History)
18 users (show)

See Also:


Attachments
poudriere build log of textproc/php56-xsl (7.98 KB, text/plain)
2015-06-29 09:25 UTC, Bernard Spil
no flags Details
Use one directory for PHP modules (3.11 KB, patch)
2015-10-08 12:57 UTC, Manuel Wiesinger
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bernard Spil freebsd_committer 2015-06-29 09:25:43 UTC
Created attachment 158155 [details]
poudriere build log of textproc/php56-xsl

Today a build of php56-xsl failed for me (see att. poudriere bulk log)

Digging a bit deeper I found the problem related to the lib directory determination in Mk/bsd.php.mk
Checks are against apache binary (not installed as a dependency using poudriere), checks against portname suffixes event/worker (apache24 doesn't have these) and checks if WITH_MPM is set to event/worker (for apache24 this is controlled using apache24_SET=EVENT/WORKER).

After setting WITH_MPM=event, the php extension built OK.
Comment 1 Daniel Austin 2015-06-29 18:35:16 UTC
I also came across this... I build all my php with thread safety, but today everything with a php dependancy failed due to this issue.
Comment 2 Baptiste Daroussin freebsd_committer 2015-06-29 19:19:45 UTC
For the record, bsd.php.mk is having a bug here for a while, which has just been shown to the wild recently due to improvements in the framework to actually track down such issues
Comment 3 Daniel Austin 2015-06-29 19:25:23 UTC
(In reply to Baptiste Daroussin from comment #2)
yep - I couldn't use the "WITH_MPM=event" fix as I use apache 2.4 as default in my builds, and poudriere bulk on a full build detected a conflict in apache22 and apache22-event-mpm... I worked around it in bsd.php.mk directly for now though :-)
Comment 4 Antoine Brodin freebsd_committer 2015-07-01 21:26:31 UTC
Most other build system enforce EXTENSION_DIR, so that it doesn't randomly changes depending on options,  for instance

OpenBSD ports:

lang/php/Makefile.inc:MODULES_SUBDIR=             lib/php-${PV}/modules
lang/php/Makefile.inc:MODULES_DIR=                ${LOCALBASE}/${MODULES_SUBDIR}
lang/php/Makefile.inc-CONFIGURE_ENV=          CFLAGS="${CFLAGS} -I${LOCALBASE}/include -pthread" \
lang/php/Makefile.inc-                        LDFLAGS="-L${LOCALBASE}/lib -pthread" \
lang/php/Makefile.inc:                    EXTENSION_DIR=${MODULES_DIR} \

pkgsrc:

lang/php/phpversion.mk:PHP_EXTENSION_DIR=        lib/php/${PHP56_RELDATE}
lang/php56/Makefile.php:CONFIGURE_ENV+=          EXTENSION_DIR="${PREFIX}/${PHP_EXTENSION_DIR}"

arch linux:

php/trunk/PKGBUILD:     EXTENSION_DIR=/usr/lib/php/modules
php/trunk/PKGBUILD-     export EXTENSION_DIR
Comment 5 Peter Wemm freebsd_committer freebsd_triage 2015-07-01 23:22:05 UTC
IMHO, the code that causes the module build to examine apache's threading state is entirely inappropriate as a heuristic to guess whether php was built with ZTS or not.

I mean, seriously:
HTTPD?=         ${LOCALBASE}/sbin/httpd
.if exists(${HTTPD})
APACHE_THR!=    ${HTTPD} -V | ${GREP} threaded
.       if ${APACHE_THR:Myes}
PHP_EXT_DIR:=   ${PHP_EXT_DIR}-zts
.       endif
.elif defined(APACHE_PORT) && (${APACHE_PORT:M*worker*} != "" || ${APACHE_PORT:M*event*} != "")
PHP_EXT_DIR:=   ${PHP_EXT_DIR}-zts
.elif defined(WITH_MPM) && (${WITH_MPM} == "worker" || ${WITH_MPM} == "event")
PHP_EXT_DIR:=   ${PHP_EXT_DIR}-zts
.endif

The only thing it doesn't seem to actually check is whether ZTS is enabled or not.
Comment 6 Baptiste Daroussin freebsd_committer 2015-07-03 14:07:19 UTC
Added ale@ the main maintainer of php in CC
Comment 7 Alban MAIRE 2015-07-27 15:13:48 UTC
Hi,

I've the same problem with net/php56-xmlrpc.


Best regards


al.
Comment 8 Adam Weinberger freebsd_committer 2015-08-28 17:26:08 UTC
ale, if this bug won't get fixed for a while, can you approve adding a message to the top of bsd.php.mk advising people to add WITH_MPM=event as a workaround?

This bug prevents building any PHP-based ports in poudriere if ZTS is enabled in php.
Comment 9 Alban MAIRE 2015-09-04 08:15:56 UTC
Nothing new?
Comment 10 commit-hook freebsd_committer 2015-09-27 18:38:05 UTC
A commit references this bug:

Author: adamw
Date: Sun Sep 27 18:37:35 UTC 2015
New revision: 398043
URL: https://svnweb.freebsd.org/changeset/ports/398043

Log:
  Add a message explaining how to fix poudriere build failures if the
  ZTS option is enabled.

  PR:		201193
  Approved by:	maintainer timeout (PR is 3 months old without
  		maintainer response)

Changes:
  head/Mk/bsd.php.mk
Comment 11 Manuel Wiesinger 2015-10-08 12:57:48 UTC
Created attachment 161826 [details]
Use one directory for PHP modules

Here is a patch for the php55 port, to use only one directory for PHP modules. This should work for 5.6 as well, but has not been tested. In my opinion it's nicer than setting a variable in /etc/make.conf
Comment 12 florian.heigl 2016-02-23 01:07:50 UTC
Still occurs on 2016Q1 branch.
Comment 13 florian.heigl 2016-04-18 02:26:35 UTC
And still occurs on 2016Q2.
Also occurs if you use DEBUG instead of ZTS.

Obviously, since it's not been fixed ;>
Comment 14 florian.heigl 2016-04-18 02:33:27 UTC
For reasons outlined in #5 it seems the healthier solution is to lock down the directory, and / or just look at the ZTS enabled yes/no instead of abusing the apache worker for this.
Comment 15 Peter Wemm freebsd_committer freebsd_triage 2016-04-19 18:02:55 UTC
php isn't tied to apache, so it really shouldn't be trying to do a promiscuous, non-build-dependency declared reach-out to inspect potential apache binaries.
Comment 16 Adam Weinberger freebsd_committer 2016-04-20 21:17:01 UTC
Comment #11 really seems like the right solution here.

If bsd.php.mk is being included and evaluated before it can detect installed php (I assume .if exists(.../php.conf) is being evaluated before the php dependency gets installed?) then the httpd evaluation couldn't possibly succeed either.

It's not like php70 and php70-zts can be installed side-by-side, so why are we putting the modules into different places?
Comment 17 Jeroen Ruigrok van der Werven freebsd_committer 2017-05-17 21:57:07 UTC
Just ran into this with a HEAD ports in poudriere wrt the debug directory:

===>   php56-xmlreader-5.6.30 depends on file: /usr/local/lib/php/20131226-debug/dom.so - not found
===>   Installing existing package /packages/All/php56-dom-5.6.30.txz
[11amd64-local-job-02] Installing php56-dom-5.6.30...
[11amd64-local-job-02] Extracting php56-dom-5.6.30: ........ done
Message from php56-dom-5.6.30:
****************************************************************************

The following line has been added to your /usr/local/etc/php/ext-20-dom.ini
configuration file to automatically load the installed extension:

extension=dom.so

****************************************************************************
===>   php56-xmlreader-5.6.30 depends on file: /usr/local/lib/php/20131226-debug/dom.so - not found
*** Error code 1

Trying to work around it with a php56-* match in make.conf to set DEBUG=no, but it was lovely to waste an hour on. :\
Comment 18 Charles P 2017-05-27 14:52:42 UTC
Be nice if this could get sorted, it's been 2 years and seems like a relatively easy fix...
Comment 19 Bernard Spil freebsd_committer 2018-04-08 08:23:44 UTC
*** Bug 218304 has been marked as a duplicate of this bug. ***
Comment 20 Bernard Spil freebsd_committer 2018-04-08 08:24:41 UTC
*** Bug 214979 has been marked as a duplicate of this bug. ***
Comment 21 Bernard Spil freebsd_committer 2018-04-08 08:25:08 UTC
*** Bug 226615 has been marked as a duplicate of this bug. ***
Comment 22 Alex Dupre freebsd_committer 2018-04-26 10:48:54 UTC
*** Bug 227762 has been marked as a duplicate of this bug. ***
Comment 23 Victor Sudakov 2019-07-03 01:25:25 UTC
*** Bug 230452 has been marked as a duplicate of this bug. ***