Everything

php

PHP standard depends on other extensions

php.internals

Piotr Roszatycki

21 years ago

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
`-

Johannes Schlueter

21 years ago

Hi Piotr,

On Friday 22 July 2005 15:15, Piotr Roszatycki wrote:

> 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

Piotr Roszatycki

21 years ago

On Friday 22 of July 2005 19:56, Johannes Schlueter 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?

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
`-

Marcus Boerger

21 years ago

Hello Piotr,

Friday, July 22, 2005, 8:41:28 PM, you wrote:

> On Friday 22 of July 2005 19:56, Johannes Schlueter 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