Re: Bundling libxml2 default?
| From: | Adam Dickmeiss | Date: | Sun, 18 May 2003 19:47:47 +0000 |
| Subject: | Re: Bundling libxml2 default? | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-1682@lists.php.net to get a copy of this message | ||
On Mon, May 19, 2003 at 12:24:21AM +0900, Moriyoshi Koizumi wrote:
> Adam Dickmeiss <adam@indexdata.dk> wrote:
>
> > > I made a patch to accomplish Adam's suggestion:
> > > http://www.voltex.jp/patches/bundle-libxml.patch.diff
> > I've applied your patch. Things didn't work quite as I expected.
> >
> > First of all, default is that Expat is enabled and bundled. libxml
> > is off by default. This is due to ",no" and ",bundled" in
> > PHP_ARG_BUNDLE in bundle/libxml/config.m4 and bunle/expat/config.m4
> > respectively. I thought we wanted libxml enabled and Expat disabled.
> > So I then used
> > --with-libxml --without-expat
> > which I assumed would choose my already installed libxml. That still
> > used the bundled version of libxml.
>
> forgot to mention the meaning of options:
>
> --with-libxml=auto => detecting the location of libxml automatically
> --with-libxml=PFX => using the libxml installed in the specified prefix
> --with-libxml=bundled => using the bundled libxml
> --with-libxml => using the bundled libxml
> default: disabled (in order to avoid confusion)
>
> --with-expat=bundled => using the bundled expat
> --with-expat=PFX => using the expat installed in the specified prefix
> --with-expat => looking for libexpat in either /usr or /usr/local
> default: enabled (--with-expat=bundled)
Is that a solution you like, or was it implemented that way because
that was a quick way to move on?
As you can guess, it was not exactly what I had in mind. But thank
you for the patch.
Again, IMHO, the whole bundling is for sysadmins who is either
unware that they already have libxml2, mysql already installed or
simply don't know how to get a separate component (either as a package
for their dist or do configure&& make && make install). Therefore,
the right way is to use the _system wide_ (note the term) libs
for PHP unless explicitly told not to.
The cost of - and danger of - running multiple versions of
a shared/static component is evident. Let's view some of them:
o Expat. The fact Expat is used by multiple parties in multiple
versions is a problem. At times I've had to configure Apache
to do
./configure --disable-rule=EXPAT ...
(say no more).
o Mysql. That big fat warning whenever you configure PHP. What's
that for? If people already have a MySQL server they probably
have the guts to compile with the libraries.. I don't know about
this at all. It just smells bad.
o libxml2 is now being bundled by default. That's going to hurt too.
Regularly D. V. will publish fixes which will not be put in
to PHP. And people will wonder why things don't work. If they
are using some other component that uses libxml2 and they do
ldd libphp5.so they will see that libxml2.so is loaded. The
problem is that that will be "fake", since there is already a
static libxml2 version inside PHP itself (with a bug in it)
That's why --with-component should use the system version if it exists.
And if a component is enabled by default, it should use the system
version.
Bundling is a bad thing. However, it is a way to ensure that
cd php-..
configure
make
will succeed on all Unix like systems.
Zeev, I've grepped in the archives and I admit there have been a lot
discussions already.
-- Adam
> Moriyoshi
--
Adam Dickmeiss mailto:adam@indexdata.dk http://www.indexdata.dk
Index Data T: +45 33410100 Mob.: 212 212 66