Re: [xslt] Fwd: symbol versioning script error
- From: Daniel Veillard <veillard redhat com>
- To: Ben Walton <bwalton artsci utoronto ca>
- Cc: XSLT List <xslt gnome org>
- Subject: Re: [xslt] Fwd: symbol versioning script error
- Date: Mon, 28 Feb 2011 10:33:24 +0800
On Sun, Feb 27, 2011 at 08:29:36PM -0500, Ben Walton wrote:
> Hi Daniel,
>
> I'm reforwarding this based on your note a few minutes ago. You may
> have handled this previously as it was outside the three month
> window.
>
> Thanks
> -Ben
>
> --- Begin forwarded message from Ben Walton ---
> From: Ben Walton <bwalton artsci utoronto ca>
> To: XSLT List <xslt gnome org>
> Date: Tue, 22 Jun 2010 21:00:56 -0400
> Subject: symbol versioning script error
>
>
> Hi All,
>
> I discovered while troubleshooting another issue that the symbol
> versioning script used by libxslt embeds LIBXML2_$version in the .so
> files that get built. This seems to be due to the xsl transform file
> in doc/ and likely results from simply copying this in from the xml2
> project.
>
> The attached patch will correct the issue, but will cause another one
> whereby the symbol names in the resulting .so files will no longer
> match those embeded in other binaries and .so files using libxslt. A
> rebuild of libxslt would need to coincide with a rebuild of everything
> linking against it.
Aie aie aie !!! Another really stupid cut and paste error :-(
If we "fix" this all the libraries requiring the old names will just
fail which is like a big big problem.
> Thoughts?
The only way to "fix" this is to also force the output of the existing
names LIBXML2_... out for the current set.
This is less problematic than it seems as
libxml2 was always with version > 2 and since libxslt stick to version < 1
they can provide a false positive.
I'm seeing right now:
paphio:~/XSLT/tests/general -> nm -D /usr/lib64/libxslt.so.1.1.26
0000000000000000 A LIBXML2_1.0.11
0000000000000000 A LIBXML2_1.0.12
0000000000000000 A LIBXML2_1.0.13
0000000000000000 A LIBXML2_1.0.16
0000000000000000 A LIBXML2_1.0.17
0000000000000000 A LIBXML2_1.0.18
0000000000000000 A LIBXML2_1.0.22
0000000000000000 A LIBXML2_1.0.24
0000000000000000 A LIBXML2_1.0.30
0000000000000000 A LIBXML2_1.0.32
0000000000000000 A LIBXML2_1.0.33
0000000000000000 A LIBXML2_1.1.0
0000000000000000 A LIBXML2_1.1.1
0000000000000000 A LIBXML2_1.1.18
0000000000000000 A LIBXML2_1.1.2
0000000000000000 A LIBXML2_1.1.20
0000000000000000 A LIBXML2_1.1.23
0000000000000000 A LIBXML2_1.1.24
0000000000000000 A LIBXML2_1.1.25
0000000000000000 A LIBXML2_1.1.26
0000000000000000 A LIBXML2_1.1.3
0000000000000000 A LIBXML2_1.1.5
0000000000000000 A LIBXML2_1.1.7
0000000000000000 A LIBXML2_1.1.9
....
So we are somehow lucky but this is nasty !
We could either:
Generate both sets for example
---------------
LIBXML2_1.0.13 {
global:
# extensions
xsltExtModuleElementPreComputeLookup;
xsltXPathGetTransformContext;
} LIBXML2_1.0.12;
and
LIBXSLT_1.0.13 {
global:
# extensions
xsltExtModuleElementPreComputeLookup;
xsltXPathGetTransformContext;
} LIBXSLT_1.0.12;
------------------
or
manage to change the logic in the stylesheet that for version > 1.1.27
then use the LIBXSLT prefix (and connect the first to LIBXML2_1.1.26)
I'm not sure what's the best approach honnestly !
> Thanks
Thanks for raising the issue !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel veillard com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]