Created attachment 546058 [details] ebuild with php in USE According to https://unit.nginx.org/ unit supports Python, PHP, Go, Perl and Ruby. Ebuild has only Perl, Python and Ruby. I wanted to add PHP support but failed. Maybe someone could help. My ebuild and emerge log are in attachment. I have 4 PHP versions/slots (5.6, 7.0, 7.1 and 7.2), all with USE=embed.
Created attachment 546060 [details] log
Looks like this test fails in /unit-1.3/auto/modules/php nxt_feature="PHP embed SAPI" nxt_feature_name="" nxt_feature_run=no nxt_feature_incs="${NXT_PHP_INCLUDE} -D" nxt_feature_libs="${NXT_PHP_LIB} ${NXT_PHP_LDFLAGS}" nxt_feature_test=" #include <php.h> #include <php_main.h> int main() { php_request_startup(); return 0; }" . auto/feature if [ $nxt_found = no ]; then $echo $echo $0: error: no PHP embed SAPI found. $echo exit 1; fi
And here's an error from that test: ---------------------------------------- checking for PHP embed SAPI /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lphp7 collect2: error: ld returned 1 exit status ---------- #include <php.h> #include <php_main.h> int main() { php_request_startup(); return 0; } ---------- cc -O2 -pipe -march=corei7 -mtune=generic -mindirect-branch=thunk -pipe -fPIC -fvisibility=hidden -O -W -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wmissing-prototypes -Werror -g -I/usr/lib64/php7.0/include/php -I/usr/lib64/php7.0/include/php/main -I/usr/lib64/ php7.0/include/php/TSRM -I/usr/lib64/php7.0/include/php/Zend -I/usr/lib64/php7.0/include/php/ext -I/usr/lib64/php7.0/include/php/ext/date/lib -o build/autotest build/autotest.c -lphp7
Found it. For PHP ebuild has to run: ./configure php --config=/usr/lib64/phpX.Y/bin/php-config --lib-path=/usr/lib64/phpX.Y/lib64 Last thing is to find proper version of PHP (X.Y). And what if there are multiple? Take default for embed or select one via USE flag? Any ideas/thoughts?
According to the documentation, unit supports multiple modules, each for one version of the language: https://unit.nginx.org/configuration/#application-objects So now is the problem of making as many modules as there are versions in PHP_TARGETS.
(In reply to manwe from comment #5) > According to the documentation, unit supports multiple modules, each for one > version of the language: > https://unit.nginx.org/configuration/#application-objects > > So now is the problem of making as many modules as there are versions in > PHP_TARGETS. Loop through the available targets and set --module= to a versioned name that this project expects. Not sure if it wants, eg., php7-1 or php7.1 or php-7.1 or something else.
See https://github.com/gentoo/gentoo/pull/9249 and https://github.com/gentoo/gentoo/pull/9278 for a discussion why PHP support was removed. I'm hoping for the PHP team to come up with a robust solution, but until then I won't enter another merry dance. In other words, as of now PHP support is indeed missing but "working as designed".
If they are unhappy with Unit itself "EDIT: Not unhappy with the ebuild, but unhappy with Unit itself." there's really not much we can do. This is how this software is written. But is it really reason to drop whole functionality? There's not need to use ENV variables (like NXT_PHP_LIB_PATH). Proper way is to launch ./configure php --config=/usr/lib64/phpX.Y/bin/php-config --lib-path=/usr/lib64/phpX.Y/lib64 --module=phpX.Y for each version with USE=embed. And it compiles fines. For now I have different problem: [ 7070.885595] unitd[100193]: segfault at 10 ip 00007ffff741c684 sp 00007fffffffcf10 error 4 in libpthread-2.27.so[7ffff7412000+1b000] Afterapplying simple demo config: { "listeners": { "*:8300": { "application": "blogs" } }, "applications": { "blogs": { "type": "php", "processes": 1, "root": "/tmp", "index": "index.php" } } } via curl -X PUT -d @x --unix-socket /run/nginx-unit.sock http://localhost/config/ I get segfault and in logs: 2018/09/06 19:04:43 [info] 100312#100312 "blogs" application started 2018/09/06 19:04:43 [info] 100312#100312 (non ABS_MODE) php root: "/tmp" 2018/09/06 19:04:43 [alert] 100183#100183 process 100312 exited on signal 11 2018/09/06 19:04:43 [warn] 100189#100189 failed to start application "blogs" 2018/09/06 19:04:43 [alert] 100189#100189 failed to apply new conf gdb doesn't show anything usefull: # gdb --args unitd --no-daemon GNU gdb (Gentoo 8.1.1 p1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from unitd...(no debugging symbols found)...done. (gdb) run Starting program: /usr/sbin/unitd --no-daemon [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 2018/09/06 19:04:34 [info] 100183#100183 unit started
I know that using --lib-path is the key, which is why I asked "Can you check if setting --lib-path works for you?" in https://github.com/gentoo/gentoo/pull/9249#issuecomment-405292368 . I have not yet seen a properly Gentoo-ish method of figuring out which PHP versions the user wants support modules built for, and how to enumerate the respective lib paths. I can make educated guesses, but to my mind that is functionality the PHP team should provide, and in an upgrade-safe manner. I don't think I am currently the proper assignee for this issue.
Can the PHP team please have a look at this enhancement request. Thanks.
(In reply to Ralph Seichter from comment #9) > I have not yet seen a properly Gentoo-ish method of figuring out which PHP > versions the user wants support modules built for Have one local USE flag for each version of PHP? That's basically what we do with extensions -- the PHP_TARGETS variable expands into a bunch of separate USE flags. > and how to enumerate the respective lib paths. Our php-ext-source-r3.eclass sets PHPPREFIX="${EPREFIX}/usr/${libdir}/${slot}" It's not perfect, but you can use that same path. It's not going to change any time soon. I've made a note in bug 586446 that it could help to make that part of the public API in a future eclass.
(In reply to Michael Orlitzky from comment #11) > Have one local USE flag for each version of PHP? That's basically what > we do with extensions -- the PHP_TARGETS variable expands into a bunch > of separate USE flags. Am I correct to assume that I should use the function php_get_slots() of php-ext-source-r3.eclass for this or is there an alternative? Trying to inherit from this eclass unfortunately tells me that "php-ext-source-r3 is not compatible with EAPI=7".
(In reply to Ralph Seichter from comment #12) > > Am I correct to assume that I should use the function php_get_slots() of > php-ext-source-r3.eclass for this or is there an alternative? You don't need to interact with the eclass, just put "php7-0", "php7-1", etc. in your local USE flags. If one of those flags is set, depend on the associated slot of PHP, and build the nginx-unit thingy for it. php_get_slots() will do the wrong thing because it will intersect the users PHP_TARGETS and the ebuild's USE_PHP. You explicitly want to ignore PHP_TARGETS for this ebuild, since it's not a PHP extension.
Thanks for the changed ebuild. BTW. Shouldn't there be also PHP in DEPEND? php5-6? ( dev-lang/php:5.6 ) php7-0? ( dev-lang/php:7.0 ) etc.
(In reply to manwe from comment #14 > BTW. Shouldn't there be also PHP in DEPEND? Michael did mention dependencies in comment #13, and I used php7-1? ( dev-lang/php:7.1[embed] ) and similar entries for other PHP versions during testing for a while, but removed them before creating the PR, because I was not certain if it was the right method.
I have looked at several other ebuilds, but I am still uncertain about the DEPEND issue, so I would appreciate advice from the PHP team in this matter. Also, I have updated the PR to use freshly released version 1.4 of NGINX-Unit.
(In reply to Brian Evans from comment #6) > Loop through the available targets and set --module= to a versioned name > that this project expects. > > Not sure if it wants, eg., php7-1 or php7.1 or php-7.1 or something else. It can be random sequence of symbols that allowed in file names and "make" targets. The module name doesn't affect functionality anyhow. Those names are needed only for the building process to distinguish modules.
(In reply to manwe from comment #8) > If they are unhappy with Unit itself "EDIT: Not unhappy with the ebuild, but > unhappy with Unit itself." there's really not much we can do. This is how > this software is written. But is it really reason to drop whole > functionality? It's not clear what makes PHP team unhappy. It would be more productive if someone will share all the concerns regarding PHP support with Unit team. There seems no clear way how to find a path to PHP library. The "php-config" isn't really useful here. In many cases the path have to be set manually using the `--lib-path` configure option. > > There's not need to use ENV variables (like NXT_PHP_LIB_PATH). Proper way is > to launch > > ./configure php --config=/usr/lib64/phpX.Y/bin/php-config > --lib-path=/usr/lib64/phpX.Y/lib64 --module=phpX.Y > > for each version with USE=embed. And it compiles fines. > > For now I have different problem: > > [ 7070.885595] unitd[100193]: segfault at 10 ip 00007ffff741c684 sp > 00007fffffffcf10 error 4 in libpthread-2.27.so[7ffff7412000+1b000] If that's still the case, could you report a bug with description of your environment and steps to reproduce to Unit github? We will investigate.
(In reply to Ralph Seichter from comment #16) > I have looked at several other ebuilds, but I am still uncertain about the > DEPEND issue, so I would appreciate advice from the PHP team in this matter. > > Also, I have updated the PR to use freshly released version 1.4 of > NGINX-Unit. I suggest to look into www-servers/uwsgi. It has almost the same building process and similar supported modules. php? ( php_targets_php5-6? ( dev-lang/php:5.6[embed] ) php_targets_php7-0? ( dev-lang/php:7.0[embed] ) php_targets_php7-1? ( dev-lang/php:7.1[embed] ) php_targets_php7-2? ( dev-lang/php:7.2[embed] ) )
(In reply to Valentin V. Bartenev from comment #19) > I suggest to look into www-servers/uwsgi. It has almost the same > building process and similar supported modules. Yeah, that's the method I described in comment #15. I have put the dependencies back into the PR today, since there have not been any objections or alternative proposals. I'm marking this issue as resolved.
(In reply to Ralph Seichter from comment #20) > (In reply to Valentin V. Bartenev from comment #19) > > > I suggest to look into www-servers/uwsgi. It has almost the same > > building process and similar supported modules. > Yeah, that's the method I described in comment #15. I have put the > dependencies back into the PR today, since there have not been any > objections or alternative proposals. > FWIW I haven't tried it but this looks OK to me.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=42c9b26103a61776489ae756f4d4bd20308c1717 commit 42c9b26103a61776489ae756f4d4bd20308c1717 Author: Ralph Seichter <github@seichter.de> AuthorDate: 2018-09-18 13:59:54 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-10-27 12:08:48 +0000 www-servers/nginx-unit: Upstream release 1.5 This ebuild version supports NGINX Unit release 1.5 and allows building PHP runtime modules. Closes: https://bugs.gentoo.org/665362 Package-Manager: Portage-2.3.49, Repoman-2.3.10 Signed-off-by: Ralph Seichter <gentoo@seichter.de> Closes: https://github.com/gentoo/gentoo/pull/9905 Signed-off-by: Michał Górny <mgorny@gentoo.org> www-servers/nginx-unit/Manifest | 1 + www-servers/nginx-unit/metadata.xml | 6 +++ www-servers/nginx-unit/nginx-unit-1.5.ebuild | 67 ++++++++++++++++++++++++++++ 3 files changed, 74 insertions(+)
