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 <mst...@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/ _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
