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

[Adrian Bunk]

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.

If libstdc++.so.6 providing both symbols is easy that would be the 
perfect solution.

If this is not easily possible or not possible at all,
we need HAVE_EXCEPTION_PTR_SINCE_GCC46 in gcc-7.

If it is clear soon [1] that armel will not be part of buster and is 
slowly dying, this "diverge from the upstream ABI" should not be 
anything to worry about.

If armel might be part of buster then HAVE_EXCEPTION_PTR_SINCE_GCC46 can 
be unset again at some point after gcc-7 is default, and I'll generate 
binNMU and Conflicts lists for handling the fallout.

Is this OK as a way forward?

> Matthias

cu
Adrian

[1] soon = after debconf this year

-- 

       "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