"5729da1 fdo#42865: privatized unique empty string symbol" - change of addsym.awk breaks the build on Mac/PPC

[Michael Stahl]

On 19/05/12 14:30, Christian Lohmaier wrote:
> Hi *,
> 
> The change
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=5729da18a1852d842bd7de05d9d7fdcbec1e9ad5
> 
> or more precise this part of it:
> diff --git a/solenv/bin/addsym.awk b/solenv/bin/addsym.awk
> index 4c18bdc..a9e64fb 100644
> --- a/solenv/bin/addsym.awk
> +++ b/solenv/bin/addsym.awk
> @@ -43,6 +43,7 @@ END {
>      print "GLIBCXX_3.4 {"
>      print "global:"
>      print "_ZGVNSt7num_put*; _ZNSt7num_put*;"
> +    print "_ZNSs4_Rep20_S_empty_rep_storageE;"
>      print "};"
>  }
>  state == 2 {
> 
> 
> breaks the build on Mac/PPC at least in neon, bridges, remotebridges.
> Or in other words probably everywhere where a map-file is used.
> http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1337397004.20611#14916
> http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1337397004.20611#28529
> http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1337397004.20611#28653
> 
> just the neon one pasted here as it is the same for all:
> ld: symbols names listed in -exported_symbols_list:
> .../../../../../unxmacxp.pro/misc/exports_neon.map not in linked
> objects
> __ZNSs4_Rep20_S_empty_rep_storageE
> 
> I don't know why it is necessary to have that added to addsym.awk,
> when it is already added to the individual mapfiles.

what individual map files do you mean? the ones modified in the commit?
those are used by gbuild modules, while addsym.awk is only used in the
dmake build system, so both are necessary.

> Even if it is necessary, from the issue it seems to me that (at least
> at the moment) only the mysql connector is affected, and furthermore
> only in debug mode. Mac/PPC uses probably won't use either of those,
> so I guess it is fine to just omit it for Mac/PPC and keep it for the
> other systems..

the bug is just about the first instance of this general problem that
was found: on platforms that use unxgcc.mk (which does not include MacOS
X incidentally), --enable-dbgutil defines the macro _GLIBCXX_DEBUG,
which changes the libstdc++ ABI in such a way that it newly depends on a
particular symbol being exported ("unique linkage") from all libraries
that somehow include the <string> header.

it is unfortunate that apparently the MacOS linker chokes on
non-existing symbols in map files (iirc the Solaris ld also has that
problem), and i'm surprised that it apparently works on MacOS X Intel
(at least no tinderbox complained); could you try to experiment a bit
what could be done to make it work for you as well?  e.g. perhaps adding
a * for wildcard makes it work, or in the worst case a platform check is
necessary.