Re: Bug#866354: armel: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6
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.
PR64735 is Debian #727621
> 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?
No, but if there is no better choice I can try to generate one.
> 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 ...
Is there a reasonable way to have both symbols on armel?
>...
> Matthias
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: