Bug#866354: armel: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6
On Sat, Jul 01, 2017 at 01:33:14PM +0200, Matthias Klose wrote:
> 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.
>...
My estimate is that it is 4 LLVM versions plus 20-50 packages unrelated
to LLVM.
Example for the latter:
(sid_armel-dchroot)bunk@abel:~$ regina-python
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/dist-packages/regina/__init__.py", line 30, in <module>
from .engine import *
ImportError: /usr/lib/libregina-engine.so.5.1: symbol _ZNSt15__exception_ptr13exception_ptrC1ERKS0_, version CXXABI_1.3.3 not defined in file libstdc++.so.6 with link time reference
>>>
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: