Re: [PHP-DEV] always building cgi...
Well I have been abroad and been reading Emails very slowly via international calls so I might have missed a few (no need for the sarcasm). What I describe is the situation I would like to see. I will try and catch up will the zillions of Email I have and see why this can't be achieved. Andi At 04:01 PM 4/15/2001 +0200, Sascha Schumann wrote: All it really requires is compiling cgi_main.c with the same flags and linking it to the libphp4.la If you had read the emails, you would have noticed the problem behind that thought. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
Okay, what about making libphp4.la contain everything but libsapi.la, and make a new final target including libsapi.la called libphp4_xxx.la, where xxx is the sapi module used. With some more minor restructuring, we can then let people build _all_ sapi modules in one go if they like. [my internet link died yesterday and I forgot to resend this] Without careful consideration, I would not say that it would require only minor restructuring. If we would implement that change, it would have a direct effect upon the installation procedure of PHP. That is not a problem with online documentation, but what about printed manuals and the dozens of books on PHP? I'd be very hesitant to change anything here which would render those descriptions invalid. On the implementation side, I'm not convinced of the usefulness of such a change. The way libphp4.la is built directly depends upon the chosen SAPI module (thread-safety, shared/static). As of today, there are only a few possible combinations. From day-to-day experience, I have yet to see an installation where web-servers run parallelly (and which use PHP/require the same build options). - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] always building cgi...
-Original Message- From: Sascha Schumann [mailto:[EMAIL PROTECTED]] documentation, but what about printed manuals and the dozens of books on PHP? I'd be very hesitant to change anything http://www.amazon.com/exec/obidos/ASIN/1861002963 I think I smell a second edition ;) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
If there was some way of building the cgi with any sapi, that would be nice. PHP as a cgi is becoming more of a utility than a cgi. Is there a way to accomplish this without changing the user compile interface much? -Jason - Original Message - From: "Sascha Schumann" [EMAIL PROTECTED] To: "Stig Sther Bakken" [EMAIL PROTECTED] Cc: "Stig Sther Bakken" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, April 12, 2001 8:54 PM Subject: Re: [PHP-DEV] always building cgi... Okay, what about making libphp4.la contain everything but libsapi.la, and make a new final target including libsapi.la called libphp4_xxx.la, where xxx is the sapi module used. With some more minor restructuring, we can then let people build _all_ sapi modules in one go if they like. [my internet link died yesterday and I forgot to resend this] Without careful consideration, I would not say that it would require only minor restructuring. If we would implement that change, it would have a direct effect upon the installation procedure of PHP. That is not a problem with online documentation, but what about printed manuals and the dozens of books on PHP? I'd be very hesitant to change anything here which would render those descriptions invalid. On the implementation side, I'm not convinced of the usefulness of such a change. The way libphp4.la is built directly depends upon the chosen SAPI module (thread-safety, shared/static). As of today, there are only a few possible combinations. From day-to-day experience, I have yet to see an installation where web-servers run parallelly (and which use PHP/require the same build options). - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
This would certainly make my life easier. By now I have a few dozen scripts that begin with #!/usr/bin/php -q So building command line interpreter (cgi sapi) and optionally one other sapi module in one go would be nice indeed. Edin If there was some way of building the cgi with any sapi, that would be nice. PHP as a cgi is becoming more of a utility than a cgi. Is there a way to accomplish this without changing the user compile interface much? -Jason - Original Message - From: "Sascha Schumann" [EMAIL PROTECTED] To: "Stig Sther Bakken" [EMAIL PROTECTED] Cc: "Stig Sther Bakken" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, April 12, 2001 8:54 PM Subject: Re: [PHP-DEV] always building cgi... Okay, what about making libphp4.la contain everything but libsapi.la, and make a new final target including libsapi.la called libphp4_xxx.la, where xxx is the sapi module used. With some more minor restructuring, we can then let people build _all_ sapi modules in one go if they like. [my internet link died yesterday and I forgot to resend this] Without careful consideration, I would not say that it would require only minor restructuring. If we would implement that change, it would have a direct effect upon the installation procedure of PHP. That is not a problem with online documentation, but what about printed manuals and the dozens of books on PHP? I'd be very hesitant to change anything here which would render those descriptions invalid. On the implementation side, I'm not convinced of the usefulness of such a change. The way libphp4.la is built directly depends upon the chosen SAPI module (thread-safety, shared/static). As of today, there are only a few possible combinations. From day-to-day experience, I have yet to see an installation where web-servers run parallelly (and which use PHP/require the same build options). - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
On the implementation side, I'm not convinced of the usefulness of such a change. The way libphp4.la is built directly depends upon the chosen SAPI module (thread-safety, shared/static). As of today, there are only a few possible combinations. From day-to-day experience, I have yet to see an installation where web-servers run parallelly (and which use PHP/require the same build options). FWIW, 99% of the time when I build PHP I build the Apache module and the CGI at the same time with the same ./configure scripts. The module is for the website and the CGI is for cron scripts, inetd daemons, etc.. I am very much in favour of a way to compile both at once. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
[Sascha Schumann [EMAIL PROTECTED]] Sascha, what symbols can sneak in to break linking? A few examples I can test with would be nice. As other people on this list have mentioned, building --with-apxs illustrates the breakage. The chosen SAPI module (i.e. sapi/apache/libsapi.la) is part of libphp4.la. Usually, the SAPI module contains calls to server-specific APIs which are resolved upon loading the SAPI module into the web-server. Those external symbols cannot be found (of course) during creating the CGI which is built using libphp4.la. Okay, what about making libphp4.la contain everything but libsapi.la, and make a new final target including libsapi.la called libphp4_xxx.la, where xxx is the sapi module used. With some more minor restructuring, we can then let people build _all_ sapi modules in one go if they like. - Stig -- Stig Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
i like the sound of that -jason - Original Message - From: "Stig Sther Bakken" [EMAIL PROTECTED] To: "Sascha Schumann" [EMAIL PROTECTED] Cc: "Stig Sther Bakken" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, April 11, 2001 1:43 PM Subject: Re: [PHP-DEV] always building cgi... [Sascha Schumann [EMAIL PROTECTED]] Sascha, what symbols can sneak in to break linking? A few examples I can test with would be nice. As other people on this list have mentioned, building --with-apxs illustrates the breakage. The chosen SAPI module (i.e. sapi/apache/libsapi.la) is part of libphp4.la. Usually, the SAPI module contains calls to server-specific APIs which are resolved upon loading the SAPI module into the web-server. Those external symbols cannot be found (of course) during creating the CGI which is built using libphp4.la. Okay, what about making libphp4.la contain everything but libsapi.la, and make a new final target including libsapi.la called libphp4_xxx.la, where xxx is the sapi module used. With some more minor restructuring, we can then let people build _all_ sapi modules in one go if they like. - Stig -- Stig Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] always building cgi...
Sorry for breaking the build guys, I promise I'll sleep more and test more next time. Sascha, what symbols can sneak in to break linking? A few examples I can test with would be nice. - Stig -- Stig Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
Sascha, what symbols can sneak in to break linking? A few examples I can test with would be nice. As other people on this list have mentioned, building --with-apxs illustrates the breakage. The chosen SAPI module (i.e. sapi/apache/libsapi.la) is part of libphp4.la. Usually, the SAPI module contains calls to server-specific APIs which are resolved upon loading the SAPI module into the web-server. Those external symbols cannot be found (of course) during creating the CGI which is built using libphp4.la. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
