Bug#945886: creduce: build-depends on package that is not in testing.

Package: creduce Version: 2.10.0-2 Severity: serious creduce build-depends on frama-c-base which is built by the frama-c source package which is not currently in testing. Either frama-c needs to be fixed to get it back in testing, creduce needs to eliminate the dependency (no idea if this is

gcc-8, libatomic and armel/raspbian

It seems that gcc-8 unconditionally builds parts of libatomic with "-march=armv7-a+fp". This was detected by Raspbian's armv7 contamination checker before the package was uploaded to raspbian. There is no such checking for Debian armel so the package was accepted there and is now being

Bug#764732: gcc-4.9: broken -O2 optimizations on armhf

Matthias Klose wrote: there exist several workarounds for it (lowering the optimization, using gcc-4.8, ...). Disabling stack protector also seems to result in a succesful compile (reducing it from strong to regular does not). -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org

Bug#764732: gcc-4.9: broken -O2 optimizations on armhf

peter green wrote: Matthias Klose wrote: there exist several workarounds for it (lowering the optimization, using gcc-4.8, ...). Disabling stack protector also seems to result in a succesful compile (reducing it from strong to regular does not). And another workaround is to use -marm

Bug#758964: gcc-4.9 assembler errors when building md5 code from fbb on arm64

Package: gcc-4.9 Version: 4.9.1-7 x-debbugs-cc: f...@packages.debian.org Control:| affects -1 fbb| While building the latest version of fbb (the previous version built successfully) for arm64 the autobuilders (both on debian-ports and debian official) ran into the following error. They were

Bug#757738: Internal compiler error in simplify_const_unary_operation while building libwebp for arm64.

peter green wrote: While building libwebp on arm64 we got two internal compiler errors. The libwebp maintainer has told me (and I have confirmed) that this bug can be worked around with -frename-registers -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject

Bug#713126: gcj-4.6: FTBFS: unsatisfiable build-dependency: automake ( 1:1.12) but 1:1.13.3-1 is to be installed

Tags 713126 +patch Thanks The attatched debdiff makes this package build in current sid. I have not tested it beyond that. No intent to NMU. diff -u gcj-4.6-4.6.4/debian/control.m4 gcj-4.6-4.6.4/debian/control.m4 --- gcj-4.6-4.6.4/debian/control.m4 +++ gcj-4.6-4.6.4/debian/control.m4 @@

Bug#731891: gcc-4.4 FTBFS on mips* with 3.8 kernel headers

tags 731891 +patch thanks The build on the porterbox was successful, debdiff attatched, no immediate intent to NMU. diff -u gcc-4.4-4.4.7/debian/changelog gcc-4.4-4.4.7/debian/changelog --- gcc-4.4-4.4.7/debian/changelog +++ gcc-4.4-4.4.7/debian/changelog @@ -1,3 +1,10 @@ +gcc-4.4 (4.4.7-5.1)

Bug#731891: gcc-4.4 FTBFS on mips* with 3.8 kernel headers

Package: gcc-4.4 Severity: serious Tags: jessie, sid In file included from ../../../../src/libgcc/../gcc/unwind-dw2.c:333: ../../../../src/libgcc/../gcc/config/mips/linux-unwind.h: In function 'mips_fallback_frame_state': ../../../../src/libgcc/../gcc/config/mips/linux-unwind.h:78: error: field

Bug#697805: gcc-4.(7|8) FTBFS on non-ubuntu based derivatives that change output of lsb_release -is

Tags 697805 +patch Thanks Taking another look I noticed there was already a variable called derivative which is set to Ubuntu for distributions that derive from Ubuntu, Debian for distributions that derive from Debian but not from Ubuntu and Unknown for systems that dervive from neither

Bug#697805: gcc-4.(7|8) FTBFS on non-ubuntu based derivatives that change output of lsb_release -is (was: gcc-4.7 fails to build with dpkg-buildpackage)

reopen 697805 retitle 697805 gcc-4.(7|8) FTBFS on non-ubuntu based derivatives that change output of lsb_release -is severity 697805 normal thanks I just ran into this issue while updating gcc in raspbian. It is a real bug IMO but it is more subtule than the original submitter realised. I

On compiler defaults and derivatives.

There are derivatives of debian that change compiler defaults (for example minimum CPU requirements). Two such derivatives are raspbian and ubuntu. First lets look at how those derivatives currently handle things. Ubuntu The ubuntu approach is to include the ubuntu specific stuff in the

gcc-4.6 gcc-defaults, gcc-mingw and wheezy

gcc-defaults in testing depends on gccgo-4.6 which is no longer built by the gcc-4.6 source package in unstable. The new gcc-defaults in unstable is blocked from migrating due to the standoff between the release team and the gcc maintainers over gcc-4.7. As a result of this gcc-4.6 cannot

Bug#657682: gcc-4.6: assembler error on armhf Error: can't resolve `.rodata' {.rodata section} - `.LPIC10' {*UND* section}

Version: 4.6.2-15 Both gmime and gmime2.4 have now been built sucessfully (one on the buildd the other on a porterbox). I am therefore closing this bug (versioned with the version that built gmime successfully. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject

Bug#659793: gcc-4.6: ICE on sparc while building audacious

forwarded 659793 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52425 thanks Matthias Klose wrote: tags 659793 + moreinfo help thanks does it work with 4.5, 4.7 (snapshot)? Works with both 4.5 and snapshot, only 4.6 seems to suffer the problem. please forward it upstream after investigating.

Bug#659793: gcc-4.6: ICE on sparc while building audacious

Package: gcc-4.6 Version: 4.6.2-14 Severity: important Attempting to build the attatched file (preprocessed output from a file that forms part of audacious) with the following command gcc -fPIC -DPIC -g -O2 -std=gnu99 -pipe -pthread -c -xcpp-output ui_fileopener.preprocessed produces

Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

Rene Engelhard wrote: Hi, Libreoffice hasn't yet been built on armhf. I consider libreoffice to be a reasonablly important package and one that we need to get in before we can claim we have a reasonablly complete port. And the segfault described on

libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

Libreoffice hasn't yet been built on armhf. I consider libreoffice to be a reasonablly important package and one that we need to get in before we can claim we have a reasonablly complete port. The reason libreoffice isn't built is because mingw-w64 is not installable. The reason mingw-w64 is

Bug#657682: gcc-4.6: assembler error on armhf Error: can't resolve `.rodata' {.rodata section} - `.LPIC10' {*UND* section}

Package: gcc-4.6 Version: 4.6.2-12 Severity: important Gmime failed to build on armhf with the following error libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../util -DGMIME_VERSION=\2.4.31\ -DGMIME_MAJOR_VERSION=2 -DGMIME_MINOR_VERSION=4 -DGMIME_MICRO_VERSION=31 -DG_LOG_DOMAIN=\gmime\

Bug#657682: gcc-4.6: assembler error on armhf Error: can't resolve `.rodata' {.rodata section} - `.LPIC10' {*UND* section}

I have reduced this to the attatched testcase sorry, screwed up trying to attatch the file in reportbug, here's the testcase. /* -*- Mode: C; tab-width: 8; indent-tabs-mode: t; c-basic-offset: 8 -*- */ /* GMime * Copyright (C) 2000-2010 Jeffrey Stedfast * * This library is free software;

Bug#656739: Old gdc binaries blocking testing migration of gcc-defaults

Package: gcc-defaults severity: important version: 1.111 gcc-defaults recently switched the default gdc to gdc-4.6 and in the process dropped the gdc binary package on architectures that don't have gdc-4.6 (armel, ia64, mips, mipsel, powerpc, s390, sparc, armhf and s390x). This is blocking

gnat in debian armhf

It seems ubuntu armhf already has gnat-4.6 but it's blocked from autobuilding in debian due to a depency loop (gnat-4.6 build-depends on gnat which depends on gnat-4.6). Can someone get this bootstrapped so libreoffice can build*? * libreoffice build-depends on mingw-w64 which is

Bug#652205: assembler errors when trying to build flint on armhf

package: gcc-4.6 severity: important version: 1.011-2 flint FTBFS on armhf with the following errors gcc -fPIC -std=c99 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -funroll-loops -I/usr/include -I/usr/include/NTL -c ZmodF.c -o

Re: Bug#623263: shibboleth-sp2: FTBFS on armel (ICE)

If there is a need to get this package building on armel again before the gcc bug is fixed it is possible to do so by building it with g++-4.4 (4.5 and 4.6 both fail) on armel. I've attatched a patch that does that. Thanks for the patch! Do you know if this will cause any problems given

Bug#617968: libstdc++6-4.5-dev: Apps that include algorithm FTBFS

After much trial and erorr I managed to reduce the problem to the attatched trivial example. I do not know enough C++ to say if this is supposed to work or not but I can say it builds with 4.4 but not 4.5. Note: i'm just doing flyby RC bug investigation (yes I know this bug is marked as

re: plink FTBFS: #error Cannot determine endianness.

tags 528659 +patch thanks It seems that gcc on debian doesn't define __{BIG|LITTLE}_ENDIAN__ or any of the equvilents the package checks for. The package has hardcoded fallbacks for some architectures but not others hence the FTBFS on some but not all debian architectures (roughly correlated

RE: Processed (with 1 errors): reopen, retitle and downgrade

did you have a look at Aurelian's patch and really check this before reopening the report? the last patch in the bug report only touches an arm specific file so i don't see how it can change the fail/non fail status on m68k. The changelog of the package doesn't say anything about m68k either.

Bug#425011: gcc-4.1: FTBFS on m68k and arm, multiple definitions of ffi_prep_closure

package:gcc-4.1 version:4.1.2-7 severity:serious from the relavent buildd logs: /bin/sh ./libtool --mode=link /build/buildd/gcc-4.1-4.1.2/build/./gcc/xgcc -B/build/buildd/gcc-4.1-4.1.2/build/./gcc/ -B/usr/arm-linux-gnu/bin/ -B/usr/arm-linux-gnu/lib/ -isystem /usr/arm-linux-gnu/include -isystem

Bug#425011: gcc-4.1: FTBFS on m68k and arm, multiple definitions of ffi_prep_closure

This type of message does not give me a warm and fuzzy feeling that makes me want to work on the Debian arm port. I'd just like to point out that you are addressing your critisism at the wrong person. your reply seems to be directed at a message from a person replying to me not to me.

Bug#422971: gcc-4.1: FTBFS on arm: Error: junk at end of line,

shouldn't this copy be closed as well.

Re: FW: RE gcc plans for the lenny cycle

So? Does that mean the bug doesn't affect GCC 4.1? In that case, I believe Peter is correct that the bug must be resolved before GCC 4.2 can enter unstable. Do you agree? That wasn't text i wrote it was text i was quoting. I was just asking if anyone knew if there was a bug report on the issue

FW: RE gcc plans for the lenny cycle

Next GCC 4.2 will be prepared to be included in unstable; a current issue is http://sourceware.org/bugzilla/show_bug.cgi?id=4302 which has to be resolved before g++-4.2 can enter unstable. That bug is marked as resolved invalid with a reply Those symbols are for glibc. Why do they have libstdc++

Bug#391410: guifrications ftbfs on powerpc buildd because of problem installing gij

package: gij-4.1 severity: grave the buildd log in question is at http://buildd.debian.org/fetch.php?pkg=guificationsver=2.13%7Ebeta3-0.1ar ch=powerpcstamp=1159970889file=logas=raw, the following is an extract from that log Setting up gij-4.1 (4.1.1-15) ... gcj-dbtool-4.1: error while loading

Bug#391410: guifrications ftbfs on powerpc buildd because of problem installing gij

This one time, at band camp, peter green said: i belive the soloution is to make gij-4.1 pre-depend on libgcj7-0 Surely a simple Depends should do the trick? according to http://packages.debian.org/unstable/devel/gij-4.1 a depends is already there. i thought pre-depends was needed