Hi,
I'm trying to compile the latest PHP without compiled-in extensions so I could
loaded them later from php.ini. Unfortunately I've found that standard
depends on spl (spl_ce_Countable) and date. At least the second is very small
library, but the first depends on libxml and other extensions, so I wouldn't
like to compile it statically.
Another thing. I can't compile readline as dynamic library. It is unfortunate,
because libedit makes that terminal can't be detached so it would be very
nice to have CLI tool with readline for inteactive work and without readline
for background work. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286356 for details about
problems with readline.
--
.''. Piotr Roszatycki, Netia SA : :' : mailto:Piotr_Roszatycki@netia.net.pl. ' mailto:dexter@debian.org
Hi Piotr,
I'm trying to compile the latest PHP without compiled-in extensions so I
could loaded them later from php.ini. Unfortunately I've found that
standard depends on spl (spl_ce_Countable) and date. At least the second is
very small library, but the first depends on libxml and other extensions,
so I wouldn't like to compile it statically.
If I got it right ext/date is just separated from standard since ext/standard
is quite big and this gives a bit more structure but be always on.
A build with spl statically compiled in is for me just a few k bigger than a
build without spl. But building spl shared wouldn't work well for two
reasons: It deals with quite engine-near stuff (like overriding the [] syntax
or __autoload()) and other extensions behave different depending on wether it
was compiled in or not (for example MySQLi's MysqliException is extended from
SPL's RuntimeException if available at compile time)
btw. I don't see a reason for building basic extensions as shared...
Another thing. I can't compile readline as dynamic library. It is
unfortunate, because libedit makes that terminal can't be detached so it
would be very nice to have CLI tool with readline for inteactive work and
without readline for background work. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286356 for details about
problems with readline.
I can't reproduce this on my readline-powered box and your link states "We
believe that the bug you reported is fixed in the latest version of libedit"
if not please report to the libedit guys or use readline. ;-)
johannes
A build with spl statically compiled in is for me just a few k bigger than
a build without spl. But building spl shared wouldn't work well for two
reasons: It deals with quite engine-near stuff (like overriding the []
syntax or __autoload()) and other extensions behave different depending on
wether it was compiled in or not (for example MySQLi's MysqliException is
extended from SPL's RuntimeException if available at compile time)btw. I don't see a reason for building basic extensions as shared...
In the other way, SPL requires compiled-in XML library because if even I can
get XML in shared extension then SPL will be without SimpleXMLIterator, etc.
Should I consider spl with simplexml as basic extensions?
I'd like to have very light php binary so it could be used as interpreter for
system scripts.
I can't reproduce this on my readline-powered box and your link states "We
believe that the bug you reported is fixed in the latest version of
libedit" if not please report to the libedit guys or use readline. ;-)
Still it is not fixed. The readline library is GPL and is not compatible with
PHP license, so the libedit is the only choise.
--
.''. Piotr Roszatycki, Netia SA : :' : mailto:Piotr_Roszatycki@netia.net.pl. ' mailto:dexter@debian.org
Hello Piotr,
Friday, July 22, 2005, 8:41:28 PM, you wrote:
A build with spl statically compiled in is for me just a few k bigger than
a build without spl. But building spl shared wouldn't work well for two
reasons: It deals with quite engine-near stuff (like overriding the []
syntax or __autoload()) and other extensions behave different depending on
wether it was compiled in or not (for example MySQLi's MysqliException is
extended from SPL's RuntimeException if available at compile time)btw. I don't see a reason for building basic extensions as shared...
In the other way, SPL requires compiled-in XML library because if even I can
get XML in shared extension then SPL will be without SimpleXMLIterator, etc.
Should I consider spl with simplexml as basic extensions?
In that case you don't need SimpleXMLIterator from SPL and that's it (done
automatically for you by your decision). And you cannot build SPL shared
anyway.
I'd like to have very light php binary so it could be used as interpreter for
system scripts.
Why must it be lightweight for that? Do you really belive that loading the
completion library from newer bash or zsh is lightweight and tiny?
Best regards,
Marcus mailto:mail@marcus-boerger.de