libxml2 woes (PHP5 and friends)

[Ryan Schmidt]

On Dec 10, 2008, at 14:57, Chris Janton wrote:

> I am a heavy user of Wordpress. Especially using the xmlrpc  
> functions (blog photos from Flickr, "external" blog editors, etc.)
>
> In the past few months this has become a large problem. Entities  
> get stripped from the text, so no links, HTML formatting etc.
>
> The apparent culprit is libxml2 post version 2.6.31
>
> No resolution from the PHP folks - see the discussion at
>
> 	http://bugs.php.net/bug.php?id=45996
>
> No resolution from the Wordpress folks - see the discussion at
>
> 	http://trac.wordpress.org/ticket/7771
>
> There's no simple fix, but apparently workarounds in some of the  
> Linux communities by forcing PHP to use expat libraries as opposed  
> to the libxml2 libraries. I don't understand the pointers to the  
> fix, which mostly appear to be changes to PHP configuration that  
> look like this
>
> 	-enable-xml=shared,%{_prefix} --with-expat-dir=%{_prefix}
> 	--with-xmlrpc=shared,%{_prefix} --with-expat-dir=%{_prefix}
>
> but I don't see the difference between those and what is in the PHP  
> configuration on macports that looks like
>
> 	 --with-libxml-dir=${prefix} \
> 	 --with-gettext=${prefix} \
> 	 --with-xml \
> 	 --with-expat-dir=${prefix} \
> 	 --with-xmlrpc \
>
> unless there is some special magic because the expat directory is  
> included on the same line as the --with-xmlrpc
>
> I could just hack the PHP portfile to try the workaround, but I  
> don't know what the "shared" means, or the repetitive declaration  
> of --with-expat-dir
>
> Or, I could just brute force the libxml2 port back to version 2.6.31
>
> Anyone out there want to weigh in on the problem? Assure me that  
> trying the hacked PHP portfile might not hurt?

Ok, I've spent some time on this problem now. I can reproduce it with  
both php5 @5.2.8_0 and php5-devel @5.3.0alpha3_1.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: simple.php
Type: text/php
Size: 360 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20081211/5be09927/attachment.bin>
-------------- next part --------------


As I understand it, this is a PHP bug because they're bypassing the  
libxml API and using internal libxml structures they were never  
supposed to be accessing. When libxml changed those internal  
structures in libxml 2.7.x, this PHP feature stopped working. So the  
PHP team needs to fix their code.

We could try to work around the problem in MacPorts in the meantime.  
The workaround Mandriva is using seems to be to force the xml  
extension specifically (ext/xml) to use expat instead of libxml,  
while keeping the rest of the extensions using libxml (since expat  
support in PHP is said to be deprecated, according to "./configure -- 
help").

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2009.0/ 
php/current/SPECS/php.spec?r1=278891&r2=281822

http://svn.mandriva.com/svn/packages/cooker/php/current/SOURCES/php- 
xml_expat_fix.diff

php5 already declares dependencies on and links with both expat and  
libxml. I made a quick attempt at making ext/xml use expat only, but  
failed. We may need what you showed above: we may need to instruct  
PHP to build ext/xml shared (instead of, presumably, statically) so  
that we can use different libraries when linking ext/xml than we do  
for the others. I will try this later. (Building the xml extension  
shared is not part of the fix that Mandriva uses; they were already  
building xml shared before. But building xml shared may turn out to  
be necessary for the fix that they did employ.)

In fact, maybe we should be building all the extensions shared  
instead of statically. I will have to look into that too.

The "shared" flag is explained in "./configure --help":

Extensions:

   --with-EXTENSION=[shared[,PATH]]

     NOTE: Not all extensions can be build as 'shared'.

     Example: --with-foobar=shared,/usr/local/foobar/

       o Builds the foobar extension as shared extension.
       o foobar package install prefix is /usr/local/foobar/


To answer your question, the order of configure arguments should not  
matter, for standard autoconf configure scripts, and repetition of  
configure arguments should also be irrelevant (though if the values  
differ, I'm not sure whether the first or last one wins).