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 via email to