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