Ok, I agree about the severity. I would recommend retitling the bug to describe the problem (mpfr4 and mpfr6 don't mix) we need to solve rather than prescribe a particular resolution though.
Cheers, Julien On January 26, 2018 6:55:47 AM GMT+01:00, Adrian Bunk <b...@debian.org> wrote: >Control: severity -1 serious > >On Thu, Jan 25, 2018 at 09:53:21PM +0200, Adrian Bunk wrote: >> Control: tags -1 - moreinfo >> >> On Thu, Jan 25, 2018 at 07:39:27PM +0100, Julien Cristau wrote: >> > Control: severity -1 normal >> > Control: tag -1 moreinfo >> > >> > On Thu, Jan 25, 2018 at 14:11:49 +0200, Adrian Bunk wrote: >> > >> > > Package: libmpfr6 >> > > Version: 4.0.0-5 >> > > Severity: serious >> > > >> > > Mixing libmpfr4 and libmpfr6 doesn't work well: >> > > >> > > flint-arb FTBFS with: >> > > /usr/bin/ld: warning: libmpfr.so.4, needed by >/usr/lib/libflint.so, may conflict with libmpfr.so.6 >> > > /usr/bin/ld: mpfr_free_func: TLS definition in >//usr/lib/x86_64-linux-gnu/libmpfr.so.4 section .tbss mismatches >non-TLS definition in >/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libmpfr.so >section .text >> > > //usr/lib/x86_64-linux-gnu/libmpfr.so.4: error adding symbols: >Bad value >> > > collect2: error: ld returned 1 exit status >> > > >> > > Some packages like fractalnow FTBFS when gcc and libmpc3 use >> > > different mpfr libraries, with a gcc ICE: >> > > ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <= >((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1)) >> > > src/fractal_compute_engine.c: In function >'FractalLoopMANDELBROTPINTAVERAGECOLORINGDISCRETECURVATURENONESINGLE': >> > > src/fractal_compute_engine.c:285:1: internal compiler error: >Aborted >> > > >> > > It is not even obvious in the latter case that this is always >only an ICE, >> > > and not sometimes a miscompilation. >> > > >> > > The libmpc3 issue is also expected to hit users who have older >gcc versions >> > > still installed, e.g. gcc-6 still installed after stretch->buster >upgrade. >> > > >> > > When the dependencies are fulfilled users can expect to have >working software, >> > > even a forced removal on stretch->buster upgrades is better than >runtime problems. >> > >> > Is this actually a problem between libmpfr4 and libmpfr6, or >libmpfr4 >> > and the new libmpfr-dev? >> >... >> >> This is a problem between libmpfr4 and libmpfr6. >> >> libmpfr-dev is not installed when gcc ICEs building mathgl.[1,2] >>... > >It is not even obvious that we will always be lucky and get an ICE, >it is even possible that in some cases gcc might end up silenty >miscompiling code. > >ICE or worse, this would be a problem for anyone still having gcc-6 >or older compiler packages from previous releases installed when >upgrading to buster. > >And without an RC bug it would already cause problems much earlier for >derivates based on testing, since mpfr4 and mpclib3 would currently >migrate to testing before gcc-7 migrates. > >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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
