Bug#866354: armel: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6
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.
Reply to: