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 p
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 shipped
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
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
w
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 usi
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 of
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
@@ -66,7
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)
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
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 neithe
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
ha
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
debia
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
migra
Package: gcc-4.6
Version: 4.6.3-1
Severity: important
Tags: patch
While working on an unofficial "hardfloat for pi" port of debian I
discovered that building the gcc-4.6 package in an environment that
identifies itself (though lsb-release) as wheezy results in the build
choosing different opti
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
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.
Do
Luke Kenneth Casson Leighton wrote:
i686-w64-mingw32-g++ is called.
that's different from mingw-w64, then.
No it's *part of* mingw-w64.
Mnigw-w64 is a fork of mingw32 and provides toolchains targetting both
32-bit and 64-bit windows. These toolchains (at least in debian, not
sure a
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
root@net
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
https://bugs.launchpad.net/ubuntu/
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 no
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;
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=\"gmim
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 the
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 uninstallable
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 Zmo
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
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 import
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 w
> 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.
> 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.
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
/u
shouldn't this copy be closed as well.
>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 iss
>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 libstd
> a buildd problem, not a package problem; will be fixed tonight.
has this been fixed and if so has the guifrications build been requeued?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 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 w
package: gij-4.1
severity: grave
the buildd log in question is at
http://buildd.debian.org/fetch.php?&pkg=guifications&ver=2.13%7Ebeta3-0.1&ar
ch=powerpc&stamp=1159970889&file=log&as=raw, the following is an extract
from that log
Setting up gij-4.1 (4.1.1-15) ...
gcj-dbtool-4.1: error while loadi
37 matches
Mail list logo
