[solved] PHP error with xsl and libxml 2.7.8

[AndrewT]

With PHP (5.2.17 and 5.3.8) built for LiteSpeed using libxml 2.7.8 and libxslt 1.2.6, scripts attempting to use the XSL support display a 503 forbidden error page. The following shows up in stderr.log:

2011-10-10 13:41:17.711 [STDERR] lsphp5test:<snip>: symbol lookup error: /opt/xslt/lib/libxslt.so.1: undefined symbol: xmlXPathCompiledEvalToBoolean

The exact same build / versions work just fine with Apache suphp.

Downgrading libxml to 2.7.7 and rebuilding libxslt to use this older version addresses this problem with LiteSpeed.

We need a fix for this with LiteSpeed and libxml 2.7.8. EasyApache uses 2.7.8 in its current builds so this is likely to be a widespread problem for those rebuilding PHP based on libraries built by EasyApache. Please advise.

[mistwang]

if you build matching PHP from WHM plugin, lsphp5 will use the same libxml as Apache suphp.

cpanel install libxml in /opt/xml2, you should not try to install another version of libxml2.
Just follow cPanel's PHP configuration.

[AndrewT]

That's exactly the problem. If you use what cPanel creates, which is now libxml 2.7.8, any script attempting to uses xsl does not work under LiteSpeed as noted. The only work around is to manually build libxml 2.7.7 and rebuild libxslt using this older libxml.

[AndrewT]

I'm still trying to identify where in the code exactly the PHP scripts are dieing but a simple example that does not work is phpSysInfo using disp=static in the URL (it defaults to disp=dynamic if you have java script enabled).

[mistwang]

try "ldd /usr/local/lsws/fcgi-bin/lsphp5"
if it does not link to /opt/xml2/lib/libxml2.so.2, the lsphp binary was not built correctly, you need to upgrade to latest 4.1.5 and "build matching PHP" again.
if the problem persist after upgrading to 4.1.5, please contact bug@litespeed with temp root access in order for us to trouble shot it.

[AndrewT]

Thanks, that helped me narrow down this issue. The --with-libxml-dir=/opt/xml2 doesn't seem to be working as one might expect. ldd reports /usr/lib64/libxml2.so.2.

Using your build matching PHP from the WHM plugin doesn't have this issue, ldd reports /opt/xml2/lib/libxml2.so. Even a fresh rebuild using the same /home/cpeasyapache/ls.src/php-5.2.17 source and configure results in the same problem.

I stumbled upon this thread which touches on the subject but I'm just curious to know what you guys are using as the work around in your own build script to address this.

[mistwang]

If you really have to build it manually, the fix is in
/home/cpeasyapache/src/cppatch/php5-fixed-lib64.patch

"Build matching PHP" apply similar fix.

[AndrewT]

Perfect. Works like a charm. Thanks!