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
