Re: Bundling libxml2 default?

From: 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

« previous php.internals (#1682) next »