On 19 August 2013 20:12, J David <[email protected]> wrote: > The big preliminary question for me would be, "Is there a specific > design reason why it isn't currently done this way?" PHP already > requires shlib's that depend on shlib's, so that functionality is > probably universally available, but I can't shake the suspicion that > maybe there is some has-to-be-supported platform or use case hiding at > the periphery that requires static linking.
I think it all was about to be as standalone as possible, e.g. you could have a CLI with builtin readline/pcntl/whatelse extensions, while mod_php could be kept lean of that and include an opcache/whatelse instead. So, I'm not sure if a libphp.so is actually something we want unconditionally... maybe if it wasn't --enable-null but something like --enable-libphp, which would create a libphp.so which would be used to link all of the specified SAPIs. Examples: Creates three static SAPIs, all with the same configure options, though: ./configure --with-apxs --enable-cli --enable-cgi ... Create each SAPI with their own configure options: ./configure --with-apxs ... ./configure --disable-cgi --enable-cli ... ... Create SAPIs which link against a libphp.so: ./configure --enable-libphp --enable-cli --enable-cgi --with-apxs ... Now that example actually points to a problem, what if I mix case 2 and 3? ./configure --enable-libphp --enable-cli --disable-cgi ... ./configure --enable-libphp --with-apxs ... Where "..." could be f.e. enable-maintainer-zts or enable-debug? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
