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

[Jonathan Adams]

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/_tg_shl.mk 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 ...

Jon

On 6 March 2012 12:14, Michael Stahl <mstahl at redhat.com> 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/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/