Summary: | Mk/Uses/php.mk setting incorrect PHP_EXT_DIR | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Bernard Spil <brnrd> | ||||||
Component: | Ports Framework | Assignee: | Alex Dupre <ale> | ||||||
Status: | Closed Overcome By Events | ||||||||
Severity: | Affects Only Me | CC: | a.maire, adamw, ale, asmodai, bdrewery, bofh, charlespigott, florian.heigl, freebsd-ports, gasol.wu, kipponi, manuel, ohartmann, peter, ports-bugs, rainer, scratch65535, tz, vas | ||||||
Priority: | --- | ||||||||
Version: | Latest | ||||||||
Hardware: | Any | ||||||||
OS: | Any | ||||||||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167984 | ||||||||
Attachments: |
|
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. 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 (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 :-) 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 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. Added ale@ the main maintainer of php in CC Hi, I've the same problem with net/php56-xmlrpc. Best regards al. 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. Nothing new? 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 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
Still occurs on 2016Q1 branch. And still occurs on 2016Q2. Also occurs if you use DEBUG instead of ZTS. Obviously, since it's not been fixed ;> 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. 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 #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? 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. :\ Be nice if this could get sorted, it's been 2 years and seems like a relatively easy fix... *** Bug 218304 has been marked as a duplicate of this bug. *** *** Bug 214979 has been marked as a duplicate of this bug. *** *** Bug 226615 has been marked as a duplicate of this bug. *** *** Bug 227762 has been marked as a duplicate of this bug. *** *** Bug 230452 has been marked as a duplicate of this bug. *** php56 and bsd.php.mk is defunct. Create a new ticket if the problem still persists. (In reply to Muhammad Moinur Rahman from comment #24) > php56 and bsd.php.mk is defunct. Create a new ticket if the problem still persists. Sorry, I do not consider FreeBSD as a platform for running PHP apps any more. |
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.