On 30.06.2017 15:22, Adrian Bunk wrote: > On Thu, Jun 29, 2017 at 02:37:27PM +0200, Matthias Klose wrote: >> 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? > > After seeing how much is broken and how many builds are failing due to > this issue, what we need ASAP is the default gcc emitting only symbols > provided by libstdc++.so.6 in unstable.
It's "only" llvm, so one option would be to build llvm using gcc-7. pinged the LLVM maintainers. > If libstdc++.so.6 providing both symbols is easy that would be the > perfect solution. that looks a little bit more complicated.
