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

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@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/