[PHP] multiple sapi (multiple bug reports)

15 years ago by jerome@loyet.net — view source — reply

unread

Hi guys,

there is several bug reports about having problem compiling differents
SAPI at once.

http://bugs.php.net/52419
http://bugs.php.net/48989
http://bugs.php.net/53271

I'm also experiencing the same problem. CLI can be compiled and build
with any other SAPI. But only one other SAPI could be compiled and
build at once.

If this is a normal behaviour, we should add an error at configure
telling that only one SAPI is supported at once.
It not, we should correct it.

Did I miss something ?

++ Jerome

15 years ago by Kalle Sommer Nielsen — view source — reply

unread

Hi Jérôme

2010/11/11 Jérôme Loyet jerome@loyet.net:

If this is a normal behaviour, we should add an error at configure
telling that only one SAPI is supported at once.
It not, we should correct it.

Did I miss something ?

On Windows we have no problems in compiling multiple SAPI's using one
./configure, so I believe it is indeed a bug on the Unix build system
causing this, so yeah I suppose it should be fixed.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

15 years ago by johannes@schlueters.de — view source — reply

unread

Hi,

there is several bug reports about having problem compiling differents
SAPI at once.

http://bugs.php.net/52419
http://bugs.php.net/48989
http://bugs.php.net/53271

I'm also experiencing the same problem. CLI can be compiled and build
with any other SAPI. But only one other SAPI could be compiled and
build at once.

If this is a normal behaviour, we should add an error at configure
telling that only one SAPI is supported at once.
It not, we should correct it.

Building multiple SAPIs should only be "required" by distributors who
want to save compile time. CLI is a special exception to this rule.

I was under the impression that a conflict might be due to the way
main/internal_functions.c is generated, while I noticed that modules
belonging to a SAPI (like the one holding apache-specific functions)
aren't registered via that file but directly from within the SAPI. (For
CLI there is a special case with internal_functions_cli.c which lists
extensions like realdine which can only be added to CLI)

There might be other conflicts though so I would be careful with adding
support for this.

johannes

15 years ago by jerome@loyet.net — view source — reply

unread

2010/11/11 Jani Taskinen jani.taskinen@iki.fi:

11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti:

Hi Jérôme

2010/11/11 Jérôme Loyetjerome@loyet.net:

If this is a normal behaviour, we should add an error at configure
telling that only one SAPI is supported at once.
It not, we should correct it.

Did I miss something ?

On Windows we have no problems in compiling multiple SAPI's using one
./configure, so I believe it is indeed a bug on the Unix build system
causing this, so yeah I suppose it should be fixed.

Sascha explained this briefly here:

php-cvs@lists.php.net/msg00413.html" rel="nofollow" target="_blank">http://www.mail-archive.com/php-cvs@lists.php.net/msg00413.html

I understand it's hard to compile mutiple SAPI (dependancies, linkage,
...). In this case, this should be clear at configure and an error
message should be shown. It's not reasonable not to be able to compile
CGI and apache2 sapi without any informations (like
http://bugs.php.net/53271).

I've made a quick patch (http://pastebin.com/jUGMtSjv) which:

move the sapi/cgi/config9.m4 to config.m4. The reason cgi sapi uses
a config9.m4 file is to be called at configure as the last SAPI.
remove the "No SAPI selected" check in sapi/cgi/config.m4. To me
it's not its job. It has to be done by configure. To me, the cgi sapi
must be like any of the others
change the cgi sapi to be disable by default. cgi sapi will be like
any other sapi (except cli), disable by default. Basically, PHP is a
programming scripting language. The CLI has to be enable by default
and other sapi have to be enabled by the user.
add a "No SAPI selected" check in configure.in, after
"esyscmd(./build/config-stubs sapi)" (after all sapi config*.m4 files
have been executed). Use CLI as default SAPI if it's not been
disabled. If all SAPI and CLI have been disabled, issue the error
message.
A a check in PHP_SELECT_SAPI (in acinclude.m4) to ensure it's been
called only once (all SAPI (except CLI) calls this macro). At second
call, an error message telling that only one SAPI can be compiled is
shown.

I don't have a huge php core background but it seems (for me at least)
the right way for users.

hope it helps.

Something called ZTS also comes to my mind..

It's not the first time ZTS comes in the discution about multiple
SAPI. I've made some tests and looked into the code of the build
chain, but I can't see how it's related. Maybe someone can enlight me
?

thx

++ jerome

15 years ago by johannes@schlueters.de — view source — reply

unread

Something called ZTS also comes to my mind..

It's not the first time ZTS comes in the discution about multiple
SAPI. I've made some tests and looked into the code of the build
chain, but I can't see how it's related. Maybe someone can enlight me
?

Some SAPIs might enable it (IIS, apache if threading is detected etc.)
while in many cases out would be better without.

johannes

15 years ago by Kalle Sommer Nielsen — view source — reply

unread

2010/11/12 Johannes Schlüter johannes@schlueters.de:

Some SAPIs might enable it (IIS, apache if threading is detected etc.)
while in many cases out would be better without.

Then wouldn't it be logically for SAPI's that require ZTS to be built
error out in their config*.m4 files unless the --enable-zts option is
used? Thats what the SAPI config.w32 files does for things like
Apache2

--
regards,

Kalle Sommer Nielsen
kalle@php.net

15 years ago by jerome@loyet.net — view source — reply

unread

2010/11/12 Jani Taskinen jani.taskinen@iki.fi:

And here's the patch:

http://pecl.php.net/~jani/patches/multi-sapi.patch

Note: It's not quite finished, the 'make install' might not work.. ;)

After a very quick try, there is a missing case: if not SAPI and no
binaries have been selected, we should trigger an error message. The
configture is terminating normaly et make does nothing (normal).

++ Jerome

--Jani

12.11.2010 2:40, Jani Taskinen kirjoitti:

I'm working on an improvement on how all binaries are build thus
enabling building all such in one go if one wants to. I already added a
check for multiple sapi modules being build, it will error out.

Stay tuned, I'll post the patch once I've tested it a bit.

--Jani

12.11.2010 0:03, Jérôme Loyet kirjoitti:

2010/11/11 Jani Taskinenjani.taskinen@iki.fi:

11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti:

Hi Jérôme

2010/11/11 Jérôme Loyetjerome@loyet.net:

If this is a normal behaviour, we should add an error at configure
telling that only one SAPI is supported at once.
It not, we should correct it.

Did I miss something ?

On Windows we have no problems in compiling multiple SAPI's using one
./configure, so I believe it is indeed a bug on the Unix build system
causing this, so yeah I suppose it should be fixed.

Sascha explained this briefly here:

php-cvs@lists.php.net/msg00413.html" rel="nofollow" target="_blank">http://www.mail-archive.com/php-cvs@lists.php.net/msg00413.html

I understand it's hard to compile mutiple SAPI (dependancies, linkage,
...). In this case, this should be clear at configure and an error
message should be shown. It's not reasonable not to be able to compile
CGI and apache2 sapi without any informations (like
http://bugs.php.net/53271).

I've made a quick patch (http://pastebin.com/jUGMtSjv) which:

move the sapi/cgi/config9.m4 to config.m4. The reason cgi sapi uses
a config9.m4 file is to be called at configure as the last SAPI.

remove the "No SAPI selected" check in sapi/cgi/config.m4. To me
it's not its job. It has to be done by configure. To me, the cgi sapi
must be like any of the others

change the cgi sapi to be disable by default. cgi sapi will be like
any other sapi (except cli), disable by default. Basically, PHP is a
programming scripting language. The CLI has to be enable by default
and other sapi have to be enabled by the user.

add a "No SAPI selected" check in configure.in, after
"esyscmd(./build/config-stubs sapi)" (after all sapi config*.m4 files
have been executed). Use CLI as default SAPI if it's not been
disabled. If all SAPI and CLI have been disabled, issue the error
message.

A a check in PHP_SELECT_SAPI (in acinclude.m4) to ensure it's been
called only once (all SAPI (except CLI) calls this macro). At second
call, an error message telling that only one SAPI can be compiled is
shown.

I don't have a huge php core background but it seems (for me at least)
the right way for users.

hope it helps.

Something called ZTS also comes to my mind..

It's not the first time ZTS comes in the discution about multiple
SAPI. I've made some tests and looked into the code of the build
chain, but I can't see how it's related. Maybe someone can enlight me
?

thx

++ jerome

15 years ago by jerome@loyet.net — view source — reply

unread

Le 12 novembre 2010 23:57, Jani Taskinen jani.taskinen@iki.fi a écrit :

I updated the patch:

http://pecl.php.net/~jani/patches/multi-sapi.patch

Now it will fail if no sapi/binary is selected. And "make install" will now
also install them all. :)

it seems to work well.

The question remains: into what branches can I commit it?
Some might think it's not a bug fix.. ;)

I don't really know. As it may changes the way package managers manage
the way to compile multiple sapi at once, it could work for them. It
would maybe be more logic to commit it in trunk.

In all the cases, I think a patch which changes the unix buildchain
have to be tested widely before commiting. what you think ?

++ Jerome

--Jani

12.11.2010 10:23, Jérôme Loyet kirjoitti:

2010/11/12 Jani Taskinenjani.taskinen@iki.fi:

And here's the patch:

http://pecl.php.net/~jani/patches/multi-sapi.patch

Note: It's not quite finished, the 'make install' might not work.. ;)

After a very quick try, there is a missing case: if not SAPI and no
binaries have been selected, we should trigger an error message. The
configture is terminating normaly et make does nothing (normal).

++ Jerome

--Jani

12.11.2010 2:40, Jani Taskinen kirjoitti:

I'm working on an improvement on how all binaries are build thus
enabling building all such in one go if one wants to. I already added a
check for multiple sapi modules being build, it will error out.

Stay tuned, I'll post the patch once I've tested it a bit.

--Jani

12.11.2010 0:03, Jérôme Loyet kirjoitti:

2010/11/11 Jani Taskinenjani.taskinen@iki.fi:

11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti:

Hi Jérôme

2010/11/11 Jérôme Loyetjerome@loyet.net:

If this is a normal behaviour, we should add an error at configure
telling that only one SAPI is supported at once.
It not, we should correct it.

Did I miss something ?

On Windows we have no problems in compiling multiple SAPI's using one
./configure, so I believe it is indeed a bug on the Unix build system
causing this, so yeah I suppose it should be fixed.

Sascha explained this briefly here:

php-cvs@lists.php.net/msg00413.html" rel="nofollow" target="_blank">http://www.mail-archive.com/php-cvs@lists.php.net/msg00413.html

I understand it's hard to compile mutiple SAPI (dependancies, linkage,
...). In this case, this should be clear at configure and an error
message should be shown. It's not reasonable not to be able to compile
CGI and apache2 sapi without any informations (like
http://bugs.php.net/53271).

I've made a quick patch (http://pastebin.com/jUGMtSjv) which:

move the sapi/cgi/config9.m4 to config.m4. The reason cgi sapi uses
a config9.m4 file is to be called at configure as the last SAPI.

remove the "No SAPI selected" check in sapi/cgi/config.m4. To me
it's not its job. It has to be done by configure. To me, the cgi sapi
must be like any of the others

change the cgi sapi to be disable by default. cgi sapi will be like
any other sapi (except cli), disable by default. Basically, PHP is a
programming scripting language. The CLI has to be enable by default
and other sapi have to be enabled by the user.

add a "No SAPI selected" check in configure.in, after
"esyscmd(./build/config-stubs sapi)" (after all sapi config*.m4 files
have been executed). Use CLI as default SAPI if it's not been
disabled. If all SAPI and CLI have been disabled, issue the error
message.

A a check in PHP_SELECT_SAPI (in acinclude.m4) to ensure it's been
called only once (all SAPI (except CLI) calls this macro). At second
call, an error message telling that only one SAPI can be compiled is
shown.

I don't have a huge php core background but it seems (for me at least)
the right way for users.

hope it helps.

Something called ZTS also comes to my mind..

It's not the first time ZTS comes in the discution about multiple
SAPI. I've made some tests and looked into the code of the build
chain, but I can't see how it's related. Maybe someone can enlight me
?

thx

++ jerome

15 years ago by Stanley Sufficool — view source — reply

unread

2010/11/13 Jérôme Loyet jerome@loyet.net:

Le 12 novembre 2010 23:57, Jani Taskinen jani.taskinen@iki.fi a écrit :

I updated the patch:

http://pecl.php.net/~jani/patches/multi-sapi.patch

Now it will fail if no sapi/binary is selected. And "make install" will now
also install them all. :)

it seems to work well.

I think Gentoo already has a multiple SAPI build in their PHP patch set.

The question remains: into what branches can I commit it?
Some might think it's not a bug fix.. ;)

I don't really know. As it may changes the way package managers manage
the way to compile multiple sapi at once, it could work for them. It
would maybe be more logic to commit it in trunk.

In all the cases, I think a patch which changes the unix buildchain
have to be tested widely before commiting. what you think ?

++ Jerome

--Jani

12.11.2010 10:23, Jérôme Loyet kirjoitti:

2010/11/12 Jani Taskinenjani.taskinen@iki.fi:

And here's the patch:

http://pecl.php.net/~jani/patches/multi-sapi.patch

Note: It's not quite finished, the 'make install' might not work.. ;)

After a very quick try, there is a missing case: if not SAPI and no
binaries have been selected, we should trigger an error message. The
configture is terminating normaly et make does nothing (normal).

++ Jerome

--Jani

12.11.2010 2:40, Jani Taskinen kirjoitti:

I'm working on an improvement on how all binaries are build thus
enabling building all such in one go if one wants to. I already added a
check for multiple sapi modules being build, it will error out.

Stay tuned, I'll post the patch once I've tested it a bit.

--Jani

12.11.2010 0:03, Jérôme Loyet kirjoitti:

2010/11/11 Jani Taskinenjani.taskinen@iki.fi:

11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti:

Hi Jérôme

2010/11/11 Jérôme Loyetjerome@loyet.net:

If this is a normal behaviour, we should add an error at configure
telling that only one SAPI is supported at once.
It not, we should correct it.

Did I miss something ?

On Windows we have no problems in compiling multiple SAPI's using one
./configure, so I believe it is indeed a bug on the Unix build system
causing this, so yeah I suppose it should be fixed.

Sascha explained this briefly here:

php-cvs@lists.php.net/msg00413.html" rel="nofollow" target="_blank">http://www.mail-archive.com/php-cvs@lists.php.net/msg00413.html

I understand it's hard to compile mutiple SAPI (dependancies, linkage,
...). In this case, this should be clear at configure and an error
message should be shown. It's not reasonable not to be able to compile
CGI and apache2 sapi without any informations (like
http://bugs.php.net/53271).

I've made a quick patch (http://pastebin.com/jUGMtSjv) which:

move the sapi/cgi/config9.m4 to config.m4. The reason cgi sapi uses
a config9.m4 file is to be called at configure as the last SAPI.

remove the "No SAPI selected" check in sapi/cgi/config.m4. To me
it's not its job. It has to be done by configure. To me, the cgi sapi
must be like any of the others

change the cgi sapi to be disable by default. cgi sapi will be like
any other sapi (except cli), disable by default. Basically, PHP is a
programming scripting language. The CLI has to be enable by default
and other sapi have to be enabled by the user.

add a "No SAPI selected" check in configure.in, after
"esyscmd(./build/config-stubs sapi)" (after all sapi config*.m4 files
have been executed). Use CLI as default SAPI if it's not been
disabled. If all SAPI and CLI have been disabled, issue the error
message.

A a check in PHP_SELECT_SAPI (in acinclude.m4) to ensure it's been
called only once (all SAPI (except CLI) calls this macro). At second
call, an error message telling that only one SAPI can be compiled is
shown.

I don't have a huge php core background but it seems (for me at least)
the right way for users.

hope it helps.

Something called ZTS also comes to my mind..

It's not the first time ZTS comes in the discution about multiple
SAPI. I've made some tests and looked into the code of the build
chain, but I can't see how it's related. Maybe someone can enlight me
?

thx

++ jerome

15 years ago by jerome@loyet.net — view source — reply

unread

Le 13 novembre 2010 20:50, Stanley Sufficool ssufficool@gmail.com a écrit :

2010/11/13 Jérôme Loyet jerome@loyet.net:

Le 12 novembre 2010 23:57, Jani Taskinen jani.taskinen@iki.fi a écrit :

I updated the patch:

http://pecl.php.net/~jani/patches/multi-sapi.patch

Now it will fail if no sapi/binary is selected. And "make install" will now
also install them all. :)

it seems to work well.

I think Gentoo already has a multiple SAPI build in their PHP patch set.

so as FreeBSD

The question remains: into what branches can I commit it?
Some might think it's not a bug fix.. ;)

I don't really know. As it may changes the way package managers manage
the way to compile multiple sapi at once, it could work for them. It
would maybe be more logic to commit it in trunk.

In all the cases, I think a patch which changes the unix buildchain
have to be tested widely before commiting. what you think ?

++ Jerome

--Jani

12.11.2010 10:23, Jérôme Loyet kirjoitti:

2010/11/12 Jani Taskinenjani.taskinen@iki.fi:

And here's the patch:

http://pecl.php.net/~jani/patches/multi-sapi.patch

Note: It's not quite finished, the 'make install' might not work.. ;)

After a very quick try, there is a missing case: if not SAPI and no
binaries have been selected, we should trigger an error message. The
configture is terminating normaly et make does nothing (normal).

++ Jerome

--Jani

12.11.2010 2:40, Jani Taskinen kirjoitti:

I'm working on an improvement on how all binaries are build thus
enabling building all such in one go if one wants to. I already added a
check for multiple sapi modules being build, it will error out.

Stay tuned, I'll post the patch once I've tested it a bit.

--Jani

12.11.2010 0:03, Jérôme Loyet kirjoitti:

2010/11/11 Jani Taskinenjani.taskinen@iki.fi:

11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti:

Hi Jérôme

2010/11/11 Jérôme Loyetjerome@loyet.net:

If this is a normal behaviour, we should add an error at configure
telling that only one SAPI is supported at once.
It not, we should correct it.

Did I miss something ?

On Windows we have no problems in compiling multiple SAPI's using one
./configure, so I believe it is indeed a bug on the Unix build system
causing this, so yeah I suppose it should be fixed.

Sascha explained this briefly here:

php-cvs@lists.php.net/msg00413.html" rel="nofollow" target="_blank">http://www.mail-archive.com/php-cvs@lists.php.net/msg00413.html

I understand it's hard to compile mutiple SAPI (dependancies, linkage,
...). In this case, this should be clear at configure and an error
message should be shown. It's not reasonable not to be able to compile
CGI and apache2 sapi without any informations (like
http://bugs.php.net/53271).

I've made a quick patch (http://pastebin.com/jUGMtSjv) which:

move the sapi/cgi/config9.m4 to config.m4. The reason cgi sapi uses
a config9.m4 file is to be called at configure as the last SAPI.

remove the "No SAPI selected" check in sapi/cgi/config.m4. To me
it's not its job. It has to be done by configure. To me, the cgi sapi
must be like any of the others

change the cgi sapi to be disable by default. cgi sapi will be like
any other sapi (except cli), disable by default. Basically, PHP is a
programming scripting language. The CLI has to be enable by default
and other sapi have to be enabled by the user.

add a "No SAPI selected" check in configure.in, after
"esyscmd(./build/config-stubs sapi)" (after all sapi config*.m4 files
have been executed). Use CLI as default SAPI if it's not been
disabled. If all SAPI and CLI have been disabled, issue the error
message.

A a check in PHP_SELECT_SAPI (in acinclude.m4) to ensure it's been
called only once (all SAPI (except CLI) calls this macro). At second
call, an error message telling that only one SAPI can be compiled is
shown.

I don't have a huge php core background but it seems (for me at least)
the right way for users.

hope it helps.

Something called ZTS also comes to my mind..

It's not the first time ZTS comes in the discution about multiple
SAPI. I've made some tests and looked into the code of the build
chain, but I can't see how it's related. Maybe someone can enlight me
?

thx

++ jerome

15 years ago by Pierre Joye — view source — reply

unread

hi,

Above patch does work. And it's also committed to trunk now. PHP 5.3
propably will not get this, RM should decide. :)

Thanks for the update. Please add a note/explanation about this change
in the UPGRADING and UPGRADING.INTERNALS (for new SAPI, if they need
to do something new, for new SAPIs).

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

15 years ago by johannes@schlueters.de — view source — reply

unread

PHP 5.3
propably will not get this, RM should decide. :)

If you are sure it doesn't break stuff go for it! Less distributors
doing strange things.

johannes