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

Jonathan Adams t12nslookup at
Tue Mar 6 06:21:27 PST 2012

I've found the files that adds maps to the compile command and added
SOLARIS as an exception so that the compile goes a lot further.

solenv/inc/ if you look for "ANDROID" before
"SHL[0-9]VERSIONMAPPARA" and add "&& "$(OS)" != "SOLARIS"" you
shouldn't have problems with maps any more.

I now just have to get past i18npool ...


On 6 March 2012 12:14, Michael Stahl <mstahl at> wrote:
> 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/
>> _ZTS*                               ../unxsoli/lib/
>> _ZGVNSt7num_put*                    ../unxsoli/lib/
>> _ZNSt7num_put*                      ../unxsoli/lib/
>> 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.
>> 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: *;"
>> 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):

More information about the LibreOffice mailing list