[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#866354: armel: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6



On 29.06.2017 06:51, Adrian Bunk wrote:
> Package: libstdc++6
> Version: 7.1.0-7
> Severity: serious
> Control: affects -1 src:mesa
> 
> mesa FTBFS on armel due to:
> 
> https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=armel&ver=17.1.3-2&stamp=1498610882&raw=0
> 
> ...
> llvm-config-4.0: relocation error: /usr/lib/llvm-4.0/bin/../lib/libLLVM-4.0.so.1: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6 with link time reference
> llvm-config-4.0: relocation error: /usr/lib/llvm-4.0/bin/../lib/libLLVM-4.0.so.1: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6 with link time reference
> llvm-config-4.0: relocation error: /usr/lib/llvm-4.0/bin/../lib/libLLVM-4.0.so.1: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6 with link time reference
> llvm-config-4.0: relocation error: /usr/lib/llvm-4.0/bin/../lib/libLLVM-4.0.so.1: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6 with link time reference
> ...
> 
> 
> My first guess would be that the #727621 fix might be missing
> or broken in GCC 7.

no, apparently it's an incomplete backport of the fix for PR64735. and it's
missing the changes to the symbol versioning. I don't think that adding the
missing bits to the gcc-6 source would make sense. The symbol is at version
GLIBCXX_3.4.15 in stretch (gcc-6), and at version GLIBCXX_3.4.23 in sid (gcc-7).

It should work when packages are rebuilt with gcc-7, and then we have to add the
now broken packages to the libstdc++6 Breaks, this should be the way forward.
To work around that now, llvm (and maybe other afected packages) could be built
using gcc-7 explicitly.

Do you have a list of affected packages?

Or work around it by defining HAVE_EXCEPTION_PTR_SINCE_GCC46 in gcc-7 and using
the GLIBCXX_3.4.15 symbols. But then we diverge from the upstream ABI, and we
should change it again when making gcc-7 the default. Not ideal either way ...

How long is armel supposed to live?

Matthias


Reply to: