Solaris linker version map annoyances (was: Re: LibreOffice / openIndiana ...)

Michael Stahl mstahl at redhat.com
Tue Mar 6 04:14:29 PST 2012


On 05/03/12 13:06, Jonathan Adams wrote:
> I'm sure I'd tried that before ... ahh yes:
> 
> Compiling: registry/tools/rdbedit.cxx
> Making:    regmerge
> Undefined                       first referenced
>  symbol                             in file
> _ZTI*                               ../unxsoli/lib/libreg.so
> _ZTS*                               ../unxsoli/lib/libreg.so
> _ZGVNSt7num_put*                    ../unxsoli/lib/libreg.so
> _ZNSt7num_put*                      ../unxsoli/lib/libreg.so
> ld: fatal: symbol referencing errors. No output written to
> .../unxsoli/bin/regmerge
> collect2: ld returned 1 exit status
> dmake:  Error code 1, while making '../unxsoli/bin/regmerge'

those _ZTI* and _ZTS* symbols need to be exported to make dynamic_cast
and exception handling work across libraries.

http://www.openoffice.org/udk/common/man/apicppclasses.html

> some of the map files have "*"s in them, I'm assuming that SUN ld map
> stuff doesn't like them ...

unfortunately the only kind of wildcard supported by Solaris ld is
"local: *;"

http://docs.oracle.com/cd/E19253-01/817-1984/chapter5-84101/index.html

> Both the version name and the symbols associated with the version
> must remain constant. To help enforce these requirements, wildcard
> expansion of the symbol names defined within a version definition is
> not supported. The number of symbols that can match a wildcard might
> differ over the course of an objects evolution. This difference can
> lead to accidental interface instability.

so it looks like there's no simple way to use the GCC map files with
Solaris ld.

AFAIR we have decided that we want to get rid of map files anyway,
because visibility markup (SAL_DLLPUBLIC etc.) works on all supported
platforms now and is easier to maintain; the map files are only retained
on Linux/GCC to retain backwards compatibility of URE libraries (because
clients such as extensions depend on the version info).

because a Solaris/GCC port doesn't maintain ABI compatibility with
anything ever shipped anyway, it would be an option to just not use map
files on this port (but that will only work on master, where the
relevant URE libraries have been converted to gbuild and the public
headers been annotated with visibility markup, which is used with MSVC
and Apple GCC).

other things that you might try: it's apparently possible to get a GCC
that is configured for Solaris ld to use GNU ld instead, using
LD_ALTEXEC (which is even documented in the man page):

http://blogs.everycity.co.uk/alasdair/2011/03/using-the-gnu-ld-linker-on-solaris/


More information about the LibreOffice mailing list