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.
<?php
$xml = '<description><a
href="http://www.google.com">Google</a></description>';
$parser = xml_parser_create();
xml_parser_set_option($parser, XML_OPTION_SKIP_WHITE, 1);
xml_parse_into_struct($parser, $xml, $vals, $index);
xml_parser_free($parser);
echo "Input:\n";
echo $xml . "\n\n";
echo "Output:\n";
echo $vals[0]['value'] . "\n";
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).
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
