[xml] libxml2/libxslt linker version scripts vs. Solaris ld

[Michael Stahl <Michael X Stahl Oracle com>]

hi all,

in order to solve this bug:
http://www.openoffice.org/issues/show_bug.cgi?id=112480
i've had to build libxml2 and libxslt with versioned symbols on Solaris.
it turns out that the version scripts that are shipped with
libxml2/libxslt only work with GNU ld, but not with Solaris ld.

my changes to make the version scripts work with Solaris ld are here:
http://hg.services.openoffice.org/hg/cws/solaris10u8/rev/4aca101677ed
http://hg.services.openoffice.org/hg/cws/solaris10u8/rev/0e826b9ac4c7

when Solaris ld sees a symbol marked as "global:" in a version script, it
always puts a reference into the symbol table, while GNU ld only seems to
do this for symbols that are actually defined in the input object files.
as a result, linking programs against libxml2/libxslt will fail, because
some of the symbols in libxml2/libxslt are not actually defined.

another difference is that Solaris ld only exports the symbols that are
explicitly marked as "global:" in the version script.

specific failures:
- libxml2: xmlDllMain seems only defined on win32 => linking xmllint fails
- libxml2: globals.h wraps all its global variable in an "#ifdef
  LIBXML_THREAD_ENABLED", and if this condition is true, actually defines
  a macro that expands to a function call.
  all of these functions are missing from the mapfile
  => linking xmllint fails
  [ with GNU ld, these function symbols are actually exported
    un-versioned, which i guess is probably not intended. ]
- libxslt: there are some symbols that are not implemented anywhere i
  could find, e.g., xsltMatchPattern, xsltTransStorageAdd/Remove
  => linking xsltproc fails
- libxslt: there are some symbols where the implementation is guarded by
  XSLT_REFACTORED macro, but this does not seem to be defined anywhere, so
  the functions do not exist => linking xsltproc fails

also, i've found it necessary to include an auto-reduction statement in
the version script to hide all non-public symbols:
  local:
    *;

it seems to me that including symbols in a generic version like
LIBXML2_1.1.10 that may or may not exist, depending on what preprocessor
macros are defined, is a questionable practice:
a dependent library or executable that depends on libxslt.so.1 with
version LIBXML2_1.1.10 may or may not run against an actual libxslt.so.1
that contains the LIBXML2_1.1.10 version.
according to the Solaris documentation, the version script does not need
to define a linear list of dependent versions; probably it would be better
to define "guarded" symbols with a distinct version (so the versions form
a tree).

but to please Solaris ld it would still be necessary to include exactly
the symbols that are actually defined; i'm not sure how to do this,
especially given that the linker version scripts seem to be generated from
some XML file.
maybe generate several version scripts with different options, or generate
fragments and concatenate them at build-time...

opinions?

regards,
 michael

-- 
ENOSIG