Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On 06/27/2018 10:03 PM, Niels Thykier wrote: > Hi, > > > As part of the interim architecture qualification for buster, we request > that DSA, the security team and the toolchain maintainers review and > update their list of known concerns for buster release architectures. > Everyone, please avoid followups to debian-po...@lists.debian.org. Unless something is relevant to *all* architectures (hint: discussion of riscv or arm issues don't qualify), keep replies to the appropriate port-specific mailing list. Thanks, Julien
Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
[s/debian-ports/debian-arm/] On 06/29/2018 09:16 AM, Uwe Kleine-König wrote: > Hello, > > On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote: >> armel/armhf: >> >> >> * Undesirable to keep the hardware running beyond 2020. armhf VM >>support uncertain. (DSA) >>- Source: [DSA Sprint report] >> >> [DSA Sprint report]: >> https://lists.debian.org/debian-project/2018/02/msg4.html > > In this report Julien Cristau wrote: > >> In short, the hardware (development boards) we're currently using to >> build armel and armhf packages aren't up to our standards, and we >> really, really want them to go away when stretch goes EOL (expected in >> 2020). We urge arm porters to find a way to build armhf packages in >> VMs or chroots on server-class arm64 hardware. > > If the concerns are mostly about the hardware not being rackable, there > is a rackable NAS by Netgear: > > > https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs > > with an armhf cpu. Not sure if cpu speed (1.2 GHz) and available RAM (2 > GiB) are good enough. The machine can run mainline Linux[1]. I think > U-Boot doesn't support this machine in mainline though. > Rackable, while good, is only part of it. The main part is remote management. I'm not seeing any mention of ipmi or anything like that in the datasheet? 2G is also way too little memory these days for a new buildd. Cheers, Julien
Bug#888422: libmpfr6 should add Breaks: libmpfr4
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 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.
Bug#888422: libmpfr6 should add Breaks: libmpfr4
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? A Breaks relationship between libmpfr4 and libmpfr6 would be very, very bad. Cheers, Julien
Bug#862514: Gcc creates illegal instructions when combining C + ASM on arm on sid
On Tue, Jun 20, 2017 at 21:33:56 +0200, Gianfranco Costamagna wrote: > control: severity -1 serious > > breaking packages is serious enough to me > https://bugs.launchpad.net/ubuntu/+source/meson/+bug/1698463 > > is an example of affected package. > > Raising the severity accordingly > You may want to get this bug reassigned to the appropriate place if you're going to do that though, i.e. not the gcc-defaults metapackage. I'm guessing gcc-6 or binutils are more likely. Cheers, Julien
Bug#770025: gcc-4.9-base: please add Breaks: gcc-4.7-base (<< 4.7.3) as in gcc-4.8-base
On Tue, Nov 18, 2014 at 13:13:35 +0100, Andreas Beckmann wrote: > Package: gcc-4.9-base > Version: 4.9.1-19 > Severity: important > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > please sync the Breaks between gcc-4.8-base and gcc-4.9-base s.t. both > include Breaks: gcc-4.7-base (<< 4.7.3). > This will ensure more consistent upgrade behavior from wheezy to jessie. > > I currently face upgrade problrms in piuparts where a minimal chroot > keeps gcc-4.7-base installed after a distupgrade (this is taken as a > reference), but a chroot with some packages to be tested will remove > gcc-4.7-base because gcc-4.8-base gets installed. After removing the > packages to be tested the resulting system does not match the > reference any more ... This doesn't make sense to me, why should gcc-4.7-base be removed? Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141126064759.ga26...@betterave.cristau.org
Bug#690172: gcc-4.7-base: adding Breaks: gcc-4.4-base (<< 4.4.7) ?
Control: severity -1 normal On Sat, Feb 16, 2013 at 15:49:49 +0100, Andreas Beckmann wrote: > Control: severity -1 serious > > On 2013-01-17 16:10, Andreas Beckmann wrote: > > Hi, > > > > how are the chances of getting this fix in sid and wheezy? > > > > I just verified that this really fixes the upgrade paths involving > > gnustep-back0.18 and friends. > > Raising the severity as this causes several incomplete upgrades from > squeeze => wheezy. After having done a lot of upgrade tests with a > "fixed" gcc-4.7-base I haven't seen any more issues due to ancient > packages from src:gcc-X.Y. (But there are still enough other packages > that need to be fixed in some way, too.) > Incomplete upgrades are by no means serious. Cheers, Julien signature.asc Description: Digital signature
Bug#677582: gcc-4.4-base: upgrade problems since removal of gcj-4.4
On Sat, Aug 4, 2012 at 11:14:15 +0200, Andreas Beckmann wrote: > # apt-get --no-y dist-upgrade > Reading package lists... Done > Building dependency tree > Reading state information... Done > Calculating upgrade... Done > The following NEW packages will be installed: > gcc-4.7-base gcj-4.7-base libapt-pkg4.12 libdb5.1 libgcj13 libgmp10 > liblzma5 libmount1 libpam-modules-bin libsemanage-common libsemanage1 > libssl1.0.0 libtinfo5 libustr-1.0-1 > multiarch-support python2.7 python2.7-minimal ucf > The following packages have been kept back: > gcc-4.4-base > The following packages will be upgraded: [...] > 76 upgraded, 18 newly installed, 0 to remove and 1 not upgraded. > [...] > > OK, that's not what we want. There shouln't be packages "kept back". > FWIW that result doesn't seem all that bad to me. If that's the only problem I wouldn't consider this bug RC. I guess there might be more issues (or in any case a different result) with libc6-dev on top though, since libc6-dev Breaks squeeze's gcc-4.4. Any chance you could test that? Thanks, Julien signature.asc Description: Digital signature
Bug#679667: gdc-4.6: FTBFS on kfreebsd
Source: gdc-4.6
Version: 0.29.1-4.6.3-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
From the kbsd-i386 build log:
> /build/buildd-gdc-4.6_0.29.1-4.6.3-1-kfreebsd-i386-8zg7gt/gdc-4.6-0.29.1-4.6.3/build/./gcc/gdc
>
> -B/build/buildd-gdc-4.6_0.29.1-4.6.3-1-kfreebsd-i386-8zg7gt/gdc-4.6-0.29.1-4.6.3/build/./gcc/
> -B/usr/i486-kfreebsd-gnu/bin/ -B/usr/i486-kfreebsd-gnu/lib/ -isystem
> /usr/i486-kfreebsd-gnu/include -isystem /usr/i486-kfreebsd-gnu/sys-include -o
> gcc/config/unix.o -Wall -g -frelease -O2 -fversion=GC_Use_Alloc_MMap
> -fversion=GC_Use_Stack_FreeBSD -fversion=GC_Use_Data_Fixed -nostdinc -pipe
> -fdeprecated -I ../../../src/libphobos -I ./i486-kfreebsd-gnu -c
> i486-kfreebsd-gnu/gcc/config/unix.d
> {standard input}: Assembler messages:
> {standard input}:103: Error: symbol type "gnu_unique_object" is supported
> only by GNU targets
> make[5]: *** [gcc/config/unix.o] Error 1
kbsd-amd64:
> build/gengtype \
> -r gtype.state
> gengtype: Internal error: abort in get_output_file_with_visibility, at
> gengtype.c:1998
> make[5]: *** [s-gtype] Error 1
Full logs at https://buildd.debian.org/status/package.php?p=gdc-4.6
Cheers,
Julien
signature.asc
Description: Digital signature
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Sun, May 13, 2012 at 19:56:15 +0200, Matthias Klose wrote: > sorry, thinko. I did mean End of May. > So we're at the end of May. Can we have that revert now, or do I need to NMU? Cheers, Julien signature.asc Description: Digital signature
Bug#673064: gcc-defaults: don't migrate to wheezy
Source: gcc-defaults Version: 1.118 Severity: serious gcc-defaults shouldn't migrate to wheezy until there's an agreement between the gcc maintainers and release team about the 4.7 situation. Cheers, Julien signature.asc Description: Digital signature
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Sun, May 13, 2012 at 19:42:21 +0200, Matthias Klose wrote: > I am only aware of these usertags: > debian...@lists.debian.org / qa-ftbfs-20120508 > do you known about a new rebuild? > No, I've seen bugs being filed from watching -bugs-rc. Cheers, Julien signature.asc Description: Digital signature
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Sun, May 13, 2012 at 18:58:42 +0200, Matthias Klose wrote: > On 13.05.2012 17:45, Philipp Kern wrote: > > On Sun, May 13, 2012 at 11:40:36AM +0200, Julien Cristau wrote: > >> On Tue, May 8, 2012 at 19:44:01 +0200, Matthias Klose wrote: > >>> The intent to get GCC changed was mentioned in the bug reports a month > >>> ago. > >> Seeing the number of new bug reports that keep popping up I still think > >> the switch should be reverted. It was bad enough with all the month old > >> bugs still open, but with many new ones (plus the misbuilds) I really > >> don't think it's reasonable to waste yet more time on this. > > which ones? are there any reports which are not tagged? I went through the > list > of Lucas' new batch and tagged the appropriate ones. > There were again some more in the last couple days. They should be tagged AFAIK. > Which misbuilds are you aware of? I don't see any tagged? > I'm aware of syslinux. I assume there will be others. > > This doesn't mean that we shouldn't have gcc-4.7 in wheezy as an > > alternative, > > just that it is highly problematic as the default at this point of the > > release > > cycle. +1 on the revert from me, sadly. > > in summary, these are getting addressed faster than these are submitted. > Please > lets wait until the end of June if to make this decision or not. > Hell no. End of June is when we'll be frozen. Not when we'll keep messing around with big toolchain changes. Cheers, Julien signature.asc Description: Digital signature
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Tue, May 8, 2012 at 19:44:01 +0200, Matthias Klose wrote: > The intent to get GCC changed was mentioned in the bug reports a month ago. Seeing the number of new bug reports that keep popping up I still think the switch should be reverted. It was bad enough with all the month old bugs still open, but with many new ones (plus the misbuilds) I really don't think it's reasonable to waste yet more time on this. Cheers, Julien signature.asc Description: Digital signature
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Tue, May 8, 2012 at 18:55:49 +0200, Matthias Klose wrote: > awesome, libchamplain ftbfs with an ICE in gcc-4.7 > yeah for switching the default compiler > doko: It looks like I'm going to take up your offer. Please fix that. > doko: you have your first problem of gcc-4.7 breaking an ongoing > transition > mbiebl: that might be the gmp10 bug > KiBi, can't reproduce the libchamplain ICE locally. could you do a > local build as well? > > and I didn't get a reply on that. > That was the gmp bug. Cheers, Julien signature.asc Description: Digital signature
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Tue, May 8, 2012 at 18:55:49 +0200, Matthias Klose wrote: > strigi was fixed, the gnome-commander and hugin builds were both tried on > brahms (and did succeed on other architectures). > Other architectures didn't switch to 4.7. > > What's worse is that at least for the last two, there were no gcc 4.7 bug > > reports for them! And don't tell me thins changed for them, since hugin is > > getting his *fourth* binNMU in a row. > > no, because it's a buildd issue, or an gmp issue, afaics. Again, please don't > blame the compiler if you can't explain a build failure. > No it ain't. > so what is the status of brahms? > It's happy since it reverted to gmp 5.0.4. Less so since it upgraded gcc to 4.7. > > You're making our job difficult. It's really ***NOT*** appreciated. > > well, not deciding on the release architectures for over a year now makes my > job difficult as well. still trying to get it done. > If you have specific concerns with a specific arch feel free to raise them on -release and the corresponding port's mailing list, and we'll take that into account. Not in this thread. Cheers, Julien signature.asc Description: Digital signature
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Mon, May 7, 2012 at 16:19:00 +, Matthias Klose wrote: > gcc-defaults (1.118) unstable; urgency=low > . >* Default to GCC 4.7 for gcc, g++, gfortran on amd64, i386, > kfreebsd-amd64, kfreebsd-i386 and hurd-i386. Please revert this change. There are still too many open bugs on http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gcc@lists.debian.org;tag=ftbfs-gcc-4.7, and it's too late in the release cycle, to change this, IMO. Cheers, Julien signature.asc Description: Digital signature
Bug#670025: libppl0.11-dev: arch-dependent files in multiarch: same package
Package: libppl0.11-dev Version: 0.11.2-6 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi, libppl0.11-dev is marked as Multi-Arch: same, but contains files in arch-independent paths with arch-specific contents: [libppl0.11-dev 0.11.2-6] usr/bin/ppl-config usr/include/ppl.hh usr/include/ppl_c.h b393a6567c12e96e5e9e9a475a579afd armel cddfab58f4adeedb5e61d255415193f8 s390 amd64 i386 powerpc sparc ia64 mips kfreebsd-i386 mipsel kfreebsd-amd64 usr/share/doc/libppl0.11-dev/CREDITS.gz 0e52e84eebf41588865742edaff7b3c0 kfreebsd-amd64 powerpc armel mips kfreebsd-i386 mipsel 99e2b9f8972ce00cfe57e3735881015e ia64 s390 sparc amd64 i386 Cheers, Julien signature.asc Description: Digital signature
Bug#670024: libppl-swi: arch-dependent files in multiarch: same package
Package: libppl-swi Version: 0.11.2-6 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi, libppl-swi is marked as Multi-Arch: same, but contains files in arch-independent paths with arch-specific contents: [libppl-swi 0.11.2-6] usr/bin/ppl_pl Cheers, Julien signature.asc Description: Digital signature
Bug#670004: libisl-dev: arch-dependent files in multiarch: same package
Package: libisl-dev Version: 0.08-1 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi, libisl-dev is marked as Multi-Arch: same, but contains files in arch-independent paths with arch-specific contents: [libisl-dev 0.08-1] usr/include/isl/stdint.h be464826d61bb8745f36d6844db83783 kfreebsd-amd64 armel armhf ia64 kfreebsd-i386 mipsel amd64 c1523ef69bff45c0e972500eb6f34ed0 mips s390 sparc i386 powerpc d8e3ddff48203b873c006df8ce224f9e s390x Cheers, Julien signature.asc Description: Digital signature
Bug#669996: libffi5-dbg: arch-dependent files in multiarch: same package
Package: libffi5-dbg Version: 3.0.10-3 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi, libffi5-dbg is marked as Multi-Arch: same, but contains files in arch-independent paths with arch-specific contents: [libffi5-dbg 3.0.10-3] usr/lib/debug/usr/lib/libffi.so.5.0.10 usr/lib/debug/usr/lib32/libffi.so.5.0.10 usr/lib/debug/usr/lib64/libffi.so.5.0.10 Cheers, Julien signature.asc Description: Digital signature
Bug#669981: gcc-4.4-base: arch-dependent files in multiarch: same package
Package: gcc-4.4-base Version: 4.4.7-1 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi, gcc-4.4-base is marked as Multi-Arch: same, but contains files in arch-independent paths with arch-specific contents: [gcc-4.4-base 4.4.7-1] usr/share/doc/gcc-4.4-base/README.Debian.gz 0716c7ca0089c6ad2a7d1151f580d1c1 armel 6bf75ba3adf5f6ec181735a47b001ae6 armhf 72bd46e5011fff9db625686c1346c181 ia64 73f463772db364b5ddb8a8e6df95651f kfreebsd-amd64 9856fc0fe21b1028ee06cc11ba6fecd1 kfreebsd-i386 9f1350d978bc929bcf830cca87b9e308 s390x amd64 b531704efa74d091bce00bc1947c0546 s390 i386 powerpc sparc mips mipsel Cheers, Julien signature.asc Description: Digital signature
Bug#656777: RM: gcc-defaults [armel armhf ia64 mips mipsel powerpc] -- NBS; no longer built
Package: ftp.debian.org Severity: normal Apparently the latest gcc-defaults stopped building the gdc package on the archs listed in $subject, so the ood packages should be removed. Cheers, Julien signature.asc Description: Digital signature
Bug#649306: gnat-4.6: FTBFS on armel (configure: error: GNAT is required to build ada)
On Sat, Nov 19, 2011 at 23:43:03 +0100, Ludovic Brenta wrote: > doko, you said merging gcc-4.6 4.6.2-4 into gnat-4.6 would fix this > FTBFS but it hasn't. The buildd log does not indicate the exact version > of gcc-4.6 installed on the machine; perhaps I should tighten the It does, it was gcc-4.6_4.6.2-4. See the 'Toolchain package versions' line. Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2020001153.gh21...@radis.cristau.org
Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)
On Sat, Nov 19, 2011 at 23:57:48 +0100, Ludovic Brenta wrote: > Perl. Nevertheless, if you would have googled for "gengtype: Internal > error: abort in get_output_file_with_visibility, at gengtype.c:1998" you > would have found #637236, which you could have used just as well to > block the transition bug. > I looked at http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gnat-4.6 which didn't have this bug. I've now marked it as affecting gnat-4.6 so it should be included in the bug page in the future. Sorry for the duplicate. Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2019230944.gg21...@radis.cristau.org
Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)
On Sat, Nov 19, 2011 at 23:32:48 +0100, Ludovic Brenta wrote: > retitle 649307 FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in > get_output_file_with_visibility, at gengtype.c:1998 > reassign 649307 src:gcc-4.6 > severity 649307 important > forcemerge 649307 637236 > thanks > > Julien and everyone else, please stop filing FTBFS bugs automatically > against gcc-4.6 or gnat-4.6. We monitor the buildds and are aware of > FTBFS, so these bugs are not useful for us and only take away some of > our precious time for triaging. Thanks. > They may not be useful to you bug they're useful to everyone else. Why are you downgrading this bug? Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2019225043.gf21...@radis.cristau.org
Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)
Source: gnat-4.6 Version: 4.6.2-2 Severity: serious Justification: fails to build from source (but built successfully in the past) See the build log at https://buildd.debian.org/status/fetch.php?pkg=gnat-4.6&arch=kfreebsd-amd64&ver=4.6.2-2&stamp=1321357341 Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2019191607.ga14...@radis.cristau.org
Bug#649306: gnat-4.6: FTBFS on armel (configure: error: GNAT is required to build ada)
Source: gnat-4.6 Version: 4.6.2-2 Severity: serious Justification: fails to build from source (but built successfully in the past) See the build log at https://buildd.debian.org/status/fetch.php?pkg=gnat-4.6&arch=armel&ver=4.6.2-2&stamp=1321391128 Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2019191457.ga14...@radis.cristau.org
Bug#633458: gcc-4.6 miscompiles libgcrypt11 on sparc
On Sun, Jul 10, 2011 at 15:26:07 +0200, Andreas Metzler wrote:
> Package: gcc-4.6
> Version: 4.6.1-1
> Severity: normal
> Blocks: 633373
>
> gcc-4.6 seems to miscompile libgcrypt11 on armel, causing total
> failure of gnutls26.
>
> ---
> (sid)ametzler@abel:~/GNUTLS$ ~/GNUTLS/2.10.5-2/usr/bin/gnutls-cli
> db.debian.org Resolving 'db.debian.org'...
> Connecting to '82.195.75.106:443'...
> *** Fatal error: Decryption has failed.
> *** Handshake has failed
> GnuTLS error: Decryption has failed.
> ---
>
I get similar failure on sparc. 1.4.6-7 was built with gcc 4.4, works.
1.4.6-8, built with gcc 4.6, fails with an unaligned access.
(sid)jcristau@sperger:~$ gnutls/usr/bin/gnutls-cli db.debian.org
Resolving 'db.debian.org'...
Connecting to '2001:41b8:202:deb:216:36ff:fe40:3906:443'...
Bus error
(sid)jcristau@sperger:~$ LD_LIBRARY_PATH=~/gcrypt-old/lib/sparc-linux-gnu
gnutls/usr/bin/gnutls-cli db.debian.org
Resolving 'db.debian.org'...
Connecting to '2001:41b8:202:deb:216:36ff:fe40:3906:443'...
- Ephemeral Diffie-Hellman parameters
- Using prime: 1024 bits
- Secret key: 1022 bits
- Peer's public key: 1023 bits
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `O=Debian,CN=db.debian.org,EMAIL=debian-ad...@debian.org', issuer
`O=Debian,CN=ca.debian.org,EMAIL=debian-ad...@debian.org', RSA key 2048 bits,
signed using RSA-SHA1, activated `2011-04-01 05:52:15 UTC', expires `2012-03-31
05:52:15 UTC', SHA-1 fingerprint `88777cfc5bd5bb4590d0be07fa24d166e98c201c'
- Certificate[1] info:
- subject `O=Debian,CN=ca.debian.org,EMAIL=debian-ad...@debian.org', issuer
`C=US,ST=Indiana,L=Indianapolis,O=Software in the Public
Interest,OU=hostmaster,CN=Certificate Authority,EMAIL=hostmas...@spi-inc.org',
RSA key 4096 bits, signed using RSA-SHA1, activated `2008-05-13 09:13:20 UTC',
expires `2018-05-10 09:13:20 UTC', SHA-1 fingerprint
`d726c9c7a22a52af1212e99342b76283aa40994c'
- Certificate[2] info:
- subject `C=US,ST=Indiana,L=Indianapolis,O=Software in the Public
Interest,OU=hostmaster,CN=Certificate Authority,EMAIL=hostmas...@spi-inc.org',
issuer `C=US,ST=Indiana,L=Indianapolis,O=Software in the Public
Interest,OU=hostmaster,CN=Certificate Authority,EMAIL=hostmas...@spi-inc.org',
RSA key 4096 bits, signed using RSA-SHA1, activated `2008-05-13 08:07:56 UTC',
expires `2018-05-11 08:07:56 UTC', SHA-1 fingerprint
`af70884383820215cd61c6bcecfd3724a990431c'
- The hostname in the certificate matches 'db.debian.org'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed
(~/gcrypt-old has libgcrypt11 1.4.6-7 unpacked)
This also causes test failures for libsoup2.4:
https://buildd.debian.org/status/fetch.php?pkg=libsoup2.4&arch=sparc&ver=2.34.3-1&stamp=1311910501
Tracked it down to the same file as the arm fail, cipher/rijndael.c,
inside do_encrypt:
Program received signal SIGBUS, Bus error.
do_decrypt (ctx=0x57988,
bx=0x55cad
"\332\347I^\234q\350\023>r|T{\347\033\216\352\367\f\266\006\t\315S\307\313\353*9d\021=\261\233\275\177v\241\223\301y\202\366\274\024{\345\364\264\327\027~\026\325Z\301y\272B\v*)\376\062JFzc^\201\37
7Y\001\067{\355\334\375\063\026\212F\032\255;r\332", ,
ax=0x55cad
"\332\347I^\234q\350\023>r|T{\347\033\216\352\367\f\266\006\t\315S\307\313\353*9d\021=\261\233\275\177v\241\223\301y\202\366\274\024{\345\364\264\327\027~\026\325Z\301y\272B\v*)\376\062JFzc^\201\37
7Y\001\067{\355\334\375\063\026\212F\032\255;r\332", ) at rijndael.c:688
688 rijndael.c: No such file or directory.
in rijndael.c
(gdb) bt full
#0 do_decrypt (ctx=0x57988,
bx=0x55cad
"\332\347I^\234q\350\023>r|T{\347\033\216\352\367\f\266\006\t\315S\307\313\353*9d\021=\261\233\275\177v\241\223\301y\202\366\274\024{\345\364\264\327\027~\026\325Z\301y\272B\v*)\376\062JFzc^\201\37
7Y\001\067{\355\334\375\063\026\212F\032\255;r\332", ,
ax=0x55cad
"\332\347I^\234q\350\023>r|T{\347\033\216\352\367\f\266\006\t\315S\307\313\353*9d\021=\261\233\275\177v\241\223\301y\202\366\274\024{\345\364\264\327\027~\026\325Z\301y\272B\v*)\376\062JFzc^\201\37
7Y\001\067{\355\334\375\063\026\212F\032\255;r\332", ) at rijndael.c:688
b = {dummy = {16843009, 0, 180696, 1}, b =
"\001\001\001\001\000\000\000\000\000\002\301\330\000\000\000\001"}
#1 0xf7654e10 in _gcry_aes_cbc_dec (context=0x57988, iv=0x57950
"U\331\033\341\275\002\251\210\227\032\363í\251", , outbuf_arg=,
inbuf_arg=, nblocks=3) at rijndael.c:794
ctx = 0x57988
outbuf = 0x55cad
"\332\347I^\234q\350\023>r|T{\347\033\216\352\367\f\266\006\t\315S\307\313\353*9d\021=\261\233\275\177v\241\223\301y\202\366\274\024{\345\364\264\327\027~\026\325Z\301y\272B\v*)\376\062JF
zc^\201\377Y\001\067{\355\334\375\063\026\212F\032\255;r\332",
inbuf = 0x55cad
"\332\347I^\234q\350\023>r|T
Bug#609690: Debian x86 32-bits built for i586 !?
On Sun, May 15, 2011 at 14:08:00 +0200, Mike Hommey wrote: > I'm wondering. Is the project at large aware that we're not building for > i486, but for i586 ? That even the maintainer doesn't know why for > sure[1] and that no changelog entry documents when or why that happened? > (nothing in debian/changelog, and the corresponding svn commit says > "Update to SVN 20100625 (r161383) from the gcc-4_5-branch.") > And that as far as I can see, this hasn't been discussed or documented > in the released notes? > To the best of my knowledge neither the release managers nor the release notes editors for squeeze were notified of this change. Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110515190558.gy2...@radis.liafa.jussieu.fr
Re: sh4 architecture into Wheezy
On Tue, Apr 26, 2011 at 16:41:23 +0200, Matthias Klose wrote: > On 04/26/2011 09:39 AM, Neil McGovern wrote: > >I woudn't be particularly happy with that unless the gcc maintainers ok > >it, and I'm still not sure that two days is also an acceptable > >timescale. > > then please drop mips and mipsel as release architectures. At least > sh4 has a workable, accessible developer machine, and people within > Debian who care about the architecture. > It turns out the criteria for adding an architecture and those for removing one aren't exactly the same. Which is good, as it means we're not adding and removing an architecture every couple of weeks depending on a couple porters free time or random hardware issues. Not saying mips and mipsel state is good, just that you should stop the nonsense. Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426163359.gb2...@radis.liafa.jussieu.fr
Re: Bug#620716: libppl0.10-dev not in unstable anymore
On Sun, Apr 3, 2011 at 18:20:09 +0200, Matthias Klose wrote: > Package: libapron-dev > Version:0.9.10-5 > Severity: serious > > libapron-dev depends on libppl0.10-dev, which doesn't exist anymore in > unstable, now removed by ftp-master. Please depend on libppl0.11-dev > instead. > Well. Or libppl-dev, so you don't break next time. Why are the libppl dev packages versioned anyhow? Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404095326.gk3...@radis.liafa.jussieu.fr
Bug#613923: gpc: uninstallable in sid
Package: gpc Version: 1.97 Severity: serious gpc-4.1 has been removed, which makes gpc (and gpc-doc) uninstallable. Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218102630.ga30...@radis.liafa.jussieu.fr
Bug#611249: gcc-4.4: Fix PR44606 concerning powerpcspe architecture
On Thu, Jan 27, 2011 at 14:20:56 +0100, Matthias Klose wrote: > Not sure, if the release team wants such kind of patches at this > stage. At least the version in unstable didn't yet migrate. I won't > do this update anyway, mostly offline until Feb 13. > No, we're only fixing release critical bugs in testing at the moment. Cheers, Julien signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 21:29:07 -0500, Matt Turner wrote: > On Mon, Nov 15, 2010 at 8:15 PM, Samuel Thibault wrote: > > Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit : > >> On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh wrote: > >> > What's the actual problem --as-needed is trying to solve? > >> > > >> > The answer is mainly unwanted libraries being linked in as a result > >> > of using pkg-config (and various other -config variants), though there > >> > are other, lesser, culprits. The pkg-config .pc files for gtk, gnome > >> > and other libraries add in many libraries, most of which aren't > >> > typically needed. > >> > > >> > The solution: fix the .pc files! > >> > > >> > Using --as-needed is merely papering over the actual root problem. > >> > It "fixes" the symptoms, but it's not addressing the actual cause. > >> > The number of packages providing broken .pc files is not large, and > >> > the number breaking due to relying on this brokenness is likely > >> > just as small. > >> > >> I can't see why you think --as-needed is fundamentally wrong or > >> unnecessary. > >> > >> Check out http://www.gentoo.org/proj/en/qa/asneeded.xml > >> > >> --as-needed has saved tons of time for upgrades like Cairo in Gentoo, > >> where Cairo had been linked to glitz which is now useless and gone. > > > > Not a problem, if Cairo was properly exposing the dep. > > > >> So > >> when people upgraded Cairo, all the software that linked against it > >> (and also unnecessarily linked against glitz) > > > > Why did it get linked against glitz? That's where the problem is. > > I think because -lglitz was in cairo's .pc file. > That should be fixed by removing -lglitz from cairo's .pc file, not by passing --as-needed to the linker. Cheers, Julien signature.asc Description: Digital signature
Re: Processed: tagging 595884
On Tue, Sep 7, 2010 at 10:43:23 +0200, Michael Tautschnig wrote: > Hi Julien, > > > Processing commands for cont...@bugs.debian.org: > > > > > tags 595884 + sid > > Bug #595884 [ppl] ppl: FTBFS in squeeze: /bin/bash: plld: command not found > > Added tag(s) sid. > > Would you mind elaborating why you re-added the sid tag? This bug is already > fixed in the version(s) in sid!? > The version tracking is enough to tell the bts this. The tag restricts what suites the bug could be open in, there's no need to use them when version tracking does the job. Cheers, Julien signature.asc Description: Digital signature
Bug#595649: gcc-4.4: broken on armel (crtbegin.o: Unknown mandatory EABI object attribute 44)
Package: gcc-4.4 Version: 4.4.4-13 Severity: grave Justification: renders package unusable See e.g. https://buildd.debian.org/fetch.cgi?pkg=base-installer&arch=armel&ver=1.111&stamp=1283683945&file=log&as=raw and a few others from arcadelt or antheil. > make[2]: Entering directory > `/build/buildd-base-installer_1.111-armel-IhuQnA/base-installer-1.111' > cc -Os -Wall -g -D_GNU_SOURCE -Os -fomit-frame-pointer -o pkgdetails > pkgdetails.c > /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/4.4.5/crtbegin.o: Unknown > mandatory EABI object attribute 44 > /usr/bin/ld: failed to merge target specific data of file > /usr/lib/gcc/arm-linux-gnueabi/4.4.5/crtbegin.o > /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_addsubdf3.o): > Unknown mandatory EABI object attribute 44 > /usr/bin/ld: failed to merge target specific data of file > /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_addsubdf3.o) > /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_muldivdf3.o): > Unknown mandatory EABI object attribute 44 > /usr/bin/ld: failed to merge target specific data of file > /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_muldivdf3.o) > /usr/bin/ld: > /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_truncdfsf2.o): Unknown > mandatory EABI object attribute 44 > /usr/bin/ld: failed to merge target specific data of file > /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_truncdfsf2.o) > /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_addsubsf3.o): > Unknown mandatory EABI object attribute 44 > /usr/bin/ld: failed to merge target specific data of file > /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_addsubsf3.o) > /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_fixsfsi.o): > Unknown mandatory EABI object attribute 44 > /usr/bin/ld: failed to merge target specific data of file > /usr/lib/gcc/arm-linux-gnueabi/4.4.5/libgcc.a(_arm_fixsfsi.o) > /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/4.4.5/crtend.o: Unknown mandatory > EABI object attribute 44 > /usr/bin/ld: failed to merge target specific data of file > /usr/lib/gcc/arm-linux-gnueabi/4.4.5/crtend.o > collect2: ld returned 1 exit status Cheers, Julien signature.asc Description: Digital signature
Bug#591155: ppl: FTBFS: Unsatisfiable build-dependency: xpdf-utils: Depends: poppler-utils
notfixed 591155 0.10.2-7 kthxbye On Sat, Jul 31, 2010 at 21:00:07 -0400, Lucas Nussbaum wrote: > > The following packages have unmet dependencies: > > xpdf-utils: Depends: poppler-utils but it is not going to be installed > > E: Broken packages > That's 586620, not a bug in this package, fixing bug state. Cheers, Julien signature.asc Description: Digital signature
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On Fri, Aug 20, 2010 at 19:33:12 +0200, Arthur Loiret wrote: > Now, to be clear, what nice things would gcc-4.5 bring to our users? > There is a complete list here [0], but those ones are, in my opinion, > very nice: > - The new link time optimiser. > - Improved C++0x support. > - Plugins support. > My understanding is that lto in 4.5 is not quite there yet. Not that I've tried it or anything. Cheers, Julien signature.asc Description: Digital signature
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On Wed, Aug 18, 2010 at 19:12:37 +0200, Ludovic Brenta wrote: > Personally, I'd be comfortable with gcc-4.5 in Squeeze except for this > part: > > > - the upload will build several runtime libraries from the 4.5 > > sources. Regression tests did pass for the runtime libs built > > from the 4.5 sources and for 4.4 using the runtime libs from > > 4.5. > > This really gives me the creeps. > > I would propose that gcc-4.5 be allowed in testing, with priority extra, > but not that the "several runtime libraries" (which ones are they?) be > built from the gcc-4.5 sources. > > Would that be acceptable to everyone? > I assume gcc-4.5 needs libgcc1 from gcc-4.5. Cheers, Julien signature.asc Description: Digital signature
Bug#582351: libffi-dev: Installs headers into /usr/include/i486-linux-gnu
On Thu, May 20, 2010 at 16:00:37 +1000, Robert Ancell wrote: > Package: libffi-dev > Version: 3.0.9-2 > Severity: grave > Tags: squeeze Please don't use distribution tags unless the bug is actually specific to that branch (as opposed to the package version). > Justification: renders package unusable > > Header files are installed in /usr/include/i486-linux-gnu/ (and > similarly named directories on other architectures), not > /usr/include. Stops pygobject from compiling. > and I suspect this is only true on ubuntu maverick because it uses i686 instead of i486 so this isn't in cpp's search path. Not the case in debian. Cheers, Julien signature.asc Description: Digital signature
Re: rebuild test of Debian packages with GCC trunk 20100107
On Thu, Jan 14, 2010 at 01:13:19 +0100, Holger Levsen wrote: > In both cases it would be nice if you'd tag those bugs (FTBFS with > gcc-4.4 and 4.5) with sid+squeeze, so that they dont show up as RC > bugs for stable, for packages which have the same version in lenny. > Except you don't want the squeeze tag for gcc-4.5 bugs, you want the squeeze+1 tag, which doesn't exist. Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517659: ppl - FTBFS: Missuse of buildd resources
On Mon, Mar 2, 2009 at 23:22:36 +0100, Michael Tautschnig wrote: > We only build the user-docs nowadays, and that actually wouldn't be necessary > if > Debian's build system did what the policy says: There is no need to re-build > the > architecture independent stuff on each and every host, but the buildd software > does not yet properly use the build-arch target. If it did, we could get rid > of > all the dependencies (the TeX stuff, doxygen and some others) that needn't get > installed and would spare the documentation building time. Bastian, if there > is > some other nice way to work around the build-arch problem, please let me know. > build the docs in the binary-indep target instead of build. Cheers, Julien -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#451047: gcc-4.2: [hppa] ICE in reload_cse_simplify_operands, at postreload.c:392
On Thu, Nov 22, 2007 at 08:00:18 +0100, Martin Michlmayr wrote: > * Martin Michlmayr <[EMAIL PROTECTED]> [2007-11-14 09:54]: > > * Julien Cristau <[EMAIL PROTECTED]> [2007-11-13 10:12]: > > > Still ICE with -O1. Runs ok with -O0. > > This is now PR34091. > > Upstream writes: > > | I view this as a critical "target" bug. However, if we find a fix, I > | don't think it should be applied to 4.2 and earlier since it's very likely > | to break something else. > > so I suggest you put in a workaround to build with -O0 on hppa (if you > haven't done so already). Thanks, I've done that shortly after filing the report (as this FTBFS was keeping libgl1-mesa-dev uninstallable on hppa). Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#451047: gcc-4.2: [hppa] ICE in reload_cse_simplify_operands, at postreload.c:392
On Tue, Nov 13, 2007 at 01:52:27 +0100, Julien Cristau wrote: > I've reproduced the error, preprocessed source is > paer.debian.org:~jcristau/mesa-7.0.2/obj-hppa-linux-gnu/debian-osmesa16/src/mesa/swrast/s_texfilter.i > (not attached here because it's over 600k). > > It builds fine with gcc-4.1, but not with gcc-snapshot 20070916-1. > Still ICE with -O1. Runs ok with -O0. Cheers, Julien
Bug#451047: gcc-4.2: [hppa] ICE in reload_cse_simplify_operands, at postreload.c:392
Package: gcc-4.2
Version: 4.2.2-3
Severity: important
Hi,
mesa FTBFS on hppa with a gcc ice:
gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main
-I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl
-I../../src/mesa/shader -I../../src/mesa/shader/grammar
-I../../src/mesa/shader/slang -I../../src/mesa/swrast
-I../../src/mesa/swrast_setup -ansi -pedantic -O2 -g -fPIC -D_POSIX_SOURCE
-D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS
-DUSE_XSHM -DHAVE_POSIX_MEMALIGN -DCHAN_BITS=16
-DDEFAULT_SOFTWARE_DEPTH_BITS=32 -ffast-math -fno-strict-aliasing
-fno-strict-aliasing -fno-strict-aliasing swrast/s_texfilter.c -o
swrast/s_texfilter.o
In file included from ../../src/mesa/main/context.h:53,
from swrast/s_texfilter.c:27:
../../src/mesa/main/imports.h:707: warning: ISO C90 does not support 'long long'
swrast/s_texfilter.c: In function 'sample_lambda_2d':
swrast/s_texfilter.c:1420: error: insn does not satisfy its constraints:
(insn 3120 1305 2618 88 swrast/s_texfilter.c:166 (set (mem/c:HI (plus:SI
(reg/f:SI 30 %r30)
(const_int -410 [0xfe66])) [0 S2 A16])
(reg:HI 74 %fr25)) 53 {*pa.md:3126} (nil)
(nil))
swrast/s_texfilter.c:1420: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:392
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
make[4]: *** [swrast/s_texfilter.o] Error 1
I've reproduced the error, preprocessed source is
paer.debian.org:~jcristau/mesa-7.0.2/obj-hppa-linux-gnu/debian-osmesa16/src/mesa/swrast/s_texfilter.i
(not attached here because it's over 600k).
It builds fine with gcc-4.1, but not with gcc-snapshot 20070916-1.
Cheers,
Julien
signature.asc
Description: Digital signature
Bug#447284: gcc-4.2: [hppa] ICE when building netgen
On Fri, Oct 19, 2007 at 12:06:02 -0600, Julien Cristau wrote: > Package: gcc-4.2 > Version: 4.2.2-3 > Severity: normal > > Hi, > > netgen fails to build on hppa, see build log at > http://buildd.debian.org/fetch.cgi?pkg=netgen&arch=hppa&ver=4.4-8&stamp=1188566736&file=log&as=raw > > I reproduced the FTBFS on paer, the preprocessed source is attached. > Still ICE with gcc-snapshot 20070916-1, with -O1 or -O2. Seems to compile fine with -O0. Cheers, Julien signature.asc Description: Digital signature
Bug#446282: hppa wrapper needs update from gij-4.1 to gij-4.2
Package: gij-4.2 Version: 4.2.1-5 Severity: grave Justification: renders package unusable $ cat debian/gij-hppa #! /bin/sh prctl= case "$(prctl --unaligned=)" in *signal) echo >&2 "$(basename $0): ignore unaligned memory accesses" prctl="prctl --unaligned=default" esac exec $prctl /usr/bin/gij-4.1.bin "$@" #! /bin/sh prctl= case "$(prctl --unaligned=)" in *signal) echo >&2 "$(basename $0): ignore unaligned memory accesses" prctl="prctl --unaligned=default" esac exec $prctl /usr/bin/gij-4.1.bin "$@" $ This needs s/4\.1/4.2/g, and the duplication should be fixed too, i guess. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#335578: ocamlopt.opt segfaults on Alpha
On Mon, Nov 7, 2005 at 18:34:54 +, Sven Luther wrote: > binutils is the likely culprit, i would say, especially given the way ocamlopt > fails, and the fact that it was a cvs snapshot only augments that fear. > > Julien, could you maybe try downgrading to the older binutils version, and > seeing what went wrong ? > Indeed, rebuilding with binutils 2.16.1-2, gcc-4.0 4.0.1-6 and libc6.1-dev 2.3.5-7, the build succeeded, and I got a working ocamlopt.opt. The problem seems to be between binutils 2.16.1-2 and 2.16.1cvs20050902-1. Dropping debian-glibc and debian-gcc from the Mail-Followup-To. Cheers, Julien Cristau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335578: ocamlopt.opt segfaults on Alpha
Hi, Starting from ocaml version 3.08.3-8, ocamlopt.opt doesn't work at all on alpha. Since 3.08.3-7 built fine, I think this is a toolchain issue. 3.08.3-7 was built with gcc-4.0 4.0.1-4, binutils 2.16.1-2 and libc6.1-dev 2.3.5-3, while 3.08.3-8 was built with gcc-4.0 4.0.1-6, binutils 2.16.1cvs20050902-1 and libc6.1-dev 2.3.5-5. Does anyone know of an alpha-related change in the toolchain between these versions, which could have caused this? Unfortunately, I wasn't able to get a meaningful backtrace with gdb (I only know that the segfault occurs at program startup). Thanks, Julien Cristau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
