On 10/23/2016 09:52 PM, Adrien Destugues wrote:
Some time ago the runtime_loader started to complain about "Failed to
get gcc version" on some libraries. This does nt seem to have too much
bad side effects (surprisingly), except the message is sent to stderr
and this confuses some configure scripts (for example cairo fails to
build).
It looks like there are two problems at play here.
1) The main way to detect this is by looking for the symbol
_gSharedObjectHaikuABI, which is included in our glue code when linking
a library. In the case I'm looking at, the symbol is present, but it has
local visibility only, so the runtime_loader ignores it.
2) When the above fails, the runtime_loader attempts a guess by looking
at the .comment section for a version string inserted there by GCC. It
expects a string starting with "GCC (GNU) ". However, the format for
that string changed and it is now "GCC (2014_03_20) " (still followed by
the gcc version). I have found files built with gcc 4.8.2 showing both
formats (in the same file - the current libz.so in our package repo),
but more recent builds (for example, the libz.so from my haikuporter
buildmaster setup) have only strings with date codes (for gcc 5.3 and
5.4 in the case of the new libz.so).
I have adjusted runtime_loader to handle the new format and fix 2.
However, I think it would be nice to also fix 1. I see two options:
a) Make the _gSharedObjectHaikuABI symbol always global. It is a GLOBAL
when I look at the .o for our glue code, however, it somehows become
local when bundled into zlib. Is there some way to force this symbol to
be exported? Ideally in LD or some system linker script that's used when
linking shared libraries, but I did not find such a file.
b) The alternative is making the runtime_loader accept the symbol even
if it is declared local. It feels a little less clean, but I don't think
it would break anything.
