Version: 0.183-1
Hello. According to my build logs, this is fixed at least in bullseye,
so I'm closing with this message.
Thanks.
reopen 924325
retitle 924325 gcc-8-cross: FTBFS because of Makefile bug: ../../gnatbind: No
such file or directory
notfixed 924325 33+rm
severity 924325 serious
thanks
I'm reopening this bug because packages in stable *must* build in stable.
While it's true that this bug has not happened in the
Package: src:gcc-9-cross-mipsen
Version: 1+c1
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in sid but it failed:
[...]
debian/rules build-indep
gcc: 9.2.1-3 / 9.1.0-10cross1
old
Package: src:gcc-defaults
Version: 1.168
Fixed: 1.181
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in stretch and this is what happened:
[...]
debian/rules build-indep
dh_testdir
rm
Package: gcc-8-cross
Version: 28
Dear Matthias:
I see this in debian/rules:
ifeq ($(JOBS),1)
JOBS := 2
endif
This was made in commit a4c6cdfc25368c1c86dfd215db99669f93f1f096
but the changelog does not say anything about it.
I believe this is related to the Makefile bug I reported in
I'm sorry that -j1 did not work for you, but this seems to fail every
time if you try in a single-CPU machine.
You can see it fail in real time here:
https://jenkins-1.reliable-builds.org/job/gcc-8-cross/
If trying in a single-CPU machine is a burden for you, please contact
me privately and I
On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:
> Is this seen with gcc-7-cross and gcc-9-cross as well?
Yes, it happened with gcc-7-cross:
https://people.debian.org/~sanvila/build-logs/gcc-7-cross/
and it also happens with gcc-9-cross:
On Sat, Mar 16, 2019 at 05:59:16PM +0100, Matthias Klose wrote:
> On 11.03.19 18:47, Santiago Vila wrote:
> > On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:
> >
> >> I have no clue, I have never seen that before, and it seems to work fine
On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:
> I have no clue, I have never seen that before, and it seems to work fine on
> the
> buildds, and in the cross-toolchain-base* package's autopkg test. Starting
> here
> a build with -j1 to see if it's reproducible.
>
> Is this
Package: src:gcc-8-cross
Version: 26
Tags: ftbfs
Hello Matthias.
I have been unable to build this package for the last 12 months:
Status: failed gcc-8-cross_4_amd64-20180218T093520Z
Status: failed gcc-8-cross_5_amd64-20180224T160324Z
Status: failed
Package: src:gcc-python-plugin
Version: 0.17-1
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in buster but it failed:
[...]
debian/rules build-indep
dh_testdir
/usr/bin/make -C docs
Package: src:gcc-8-cross-mipsen
Version: 2~c1
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in buster but it failed:
dpkg-buildpackage
-
dpkg-buildpackage: info:
Package: src:gcc-6-cross
Version: 21
Severity: serious
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:
[...]
debian/rules build-indep
gcc: 6.3.0-14 /
Greetings.
Could anybody tell me is this optimization bug on ARM was finally fixed...
* in gcc-4.9 as released with jessie?
* in gcc-6 as the default compiler in stretch?
I ask because I added this workaround to unzip's debian/rules:
ifeq ($(DEB_HOST_ARCH),armhf)
CFLAGS :=
Sorry, did not see the part about internal compiler error in the buld log
itself. Still amazed that you can be so sure that it's hardware related when he
is using virtual machines.
Thanks.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sat, Dec 03, 2016 at 10:08:33AM +0100, Lucas Nussbaum wrote:
> Just for the record: I can still reproduce this failure.
Then, IMHO, you should reopen the bug.
I bet it's a Makefile bug related to parallel building, because my
autobuilders are single-CPU and I also have this in my .sbuilrc
On Wed, Nov 23, 2016 at 12:26:18AM +0100, Matthias Klose wrote:
> > What would be the right package for a bug in one of GCC Makefiles, then?
> >
> > What if Lucas was able to reproduce this in two different machines and
> > the failure and the error message was the same? Would you discard
> >
On Sat, 19 Nov 2016, Matthias Klose wrote:
> > It's unlikely a hardware problem because the build was made in a
> > virtual machine and the build was tried twice. This is written
> > in the bug report itself.
> >
> > This is a lot more likely to be a bug which happens randomly,
> > for example,
On Sat, 19 Nov 2016, Matthias Klose wrote:
> On 19.11.2016 07:40, Lucas Nussbaum wrote:
> > Source: gcc-5
> > Version: 5.4.1-3
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20161118 qa-ftbfs
> > Justification: FTBFS on amd64
> >
> > Hi,
>
On Thu, 4 Aug 2016, Santiago Vila wrote:
> In particular, the size of "lto1" went from 20 MB to 144 MB.
> Is this really normal/expected?
Hmm, lto1 was stripped in GCC 5 (stretch) and now it's unstripped again
(sid, GCC 6). Is this intended or accidental?
Thanks.
Hello Matthias.
With GCC 6 as the default, the size of a minimal build system has grown
by about 150 MB.
In particular, the size of "lto1" went from 20 MB to 144 MB.
Is this really normal/expected?
While we are at it, this bug is marked as "forwarded". Are there any
news from the upstream
Package: src:gcc-5-cross-ports
Version: 9
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
patching file
Package: src:gcc-5-cross
Version: 23
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
patching file
Thanks a lot, Andreas, for looking at this!
Would you take a look at this one?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818872
It's apparently the "same" bug, so most likely the fix for #818873
would also work for #818872 as well.
Thanks.
On Fri, Apr 22, 2016 at 12:22:33AM +0200, Matthias Klose wrote:
> On 22.04.2016 00:11, Santiago Vila wrote:
> >The problem with that is that it breaks the expectation that testing
> >is in an "always releaseable" state.
> >
> >Sure, the file /etc/debia
On Thu, 30 Apr 2015, Matthias Klose wrote:
> On 04/30/2015 10:43 PM, Daniel Serpell wrote:
> > Currently, gcc-5 packages are really big because the files under
> > /usr/lib/gcc/x86_64-linux-gnu/5 are not stripped, and each one of
> > lto1, cc1 and cc1plus is about 130MB.
> >
> > Please, can
On Mon, Mar 21, 2016 at 09:02:48AM +, Santiago Vila wrote:
> Package: src:gcc-5-cross-ports
> Version: 7
For the record: Version 3 was ok (in case it helps).
[ I usually build every version as they reach testing, but this package
was excluded on purpose because it was too big. I ha
On Mon, Mar 21, 2016 at 08:56:27PM +0100, Matthias Klose wrote:
> Control: tags -1 + help
>
> On 21.03.2016 10:02, Santiago Vila wrote:
> >I tried to build this package with "dpkg-buildpackage -A"
> >(i.e. only architecture-independent packages), and it failed:
&g
Package: src:gcc-5-cross-ports
Version: 7
User: sanv...@debian.org
Usertags: binary-indep
Severity: important
Dear maintainer:
I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:
Package: src:gcc-5-cross
Version: 20
User: sanv...@debian.org
Usertags: binary-indep
Severity: important
Dear maintainer:
I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:
severity 764732 serious
thanks
On Fri, 10 Oct 2014, Hector Oron wrote:
Package: gcc-4.9
Version: 4.9.1-16
Severity: important
Hello,
Found a FTBFS while trying to build unzip package in Debian/sid on armhf
host.
[...]
Yesterday, I uploaded unzip 6.0-13 fixing several security
Hello.
Latest m4 FTBFS on several architectures, for different reasons.
On hppa, it seems to trigger a gcc bug:
gcc -std=gnu99 -g -Wall -O2 -o test-fpurge test-fpurge.o libtests.a
../lib/libm4.a libtests.a
collect2: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char
*)
On Sun, 14 Aug 2005, Marco d'Itri wrote:
Package: gcc-4.0
Version: 4.0.0-12
Severity: important
Compiling tin 1.7.10+20050727 on m68k fails.
gcc -DHAVE_CONFIG_H -I. -I../include -I/usr/include
-DLOCALEDIR=\/usr/share/locale\ -I../include -DUSE_CANLOCK -D_GNU_SOURCE
-g -O2 -c
On Wed, 4 May 2005, Michael Banck wrote:
On Mon, May 02, 2005 at 06:09:04PM +0200, Matthias Klose wrote:
Anyway, back to the gcc-3.4 build log:
./xgcc -B./ -B/usr/i586-gnu/bin/ -isystem /usr/i586-gnu/include
-isystem /usr/i586-gnu/sys-include
retitle 302995 fastjar: postinst does not check for errors
reassign 302995 fastjar
severity 302995 serious
thanks
On Mon, 4 Apr 2005, Scott James Remnant wrote:
On Mon, 2005-04-04 at 02:13 +0200, Santiago Vila wrote:
On Sun, 3 Apr 2005, Blars Blarson wrote:
gettext failed to build
retitle 302995 fastjar: postinst does not check for errors
reassign 302995 fastjar
severity 302995 serious
thanks
I hope it works now. See http://bugs.debian.org/302995
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Fri, 9 Jan 2004, Matthias Klose wrote:
reassign 225039 pine
thanks
It's not a bug. By default it is trying to build 64-bit, so it isn't
working.
Either prepend sparc32 to the command, or touch /etc/disable_64_gcc.
I don't fully understand, could you please elaborate?
Why should
On 5 Feb 2002, Stephen Zander wrote:
Santiago == Santiago Vila [EMAIL PROTECTED] writes:
Santiago What about the other java compilers? It is true, for
Santiago example, that for each architecture that will be
Santiago released in woody there is at least some java compiler
Matthias Klose wrote:
Santiago Vila writes:
Is there any particular reason why gcj does not set up a symlink
javac - gcj using the alternatives mechanism, as jikes used to do before
Bug #43730 was reported?
an alternative should only be provided, if a reasonable set of options
match
Hello.
Is there any particular reason why gcj does not set up a symlink
javac - gcj using the alternatives mechanism, as jikes used to do before
Bug #43730 was reported?
( The new gettext-0.11 checks for a java compiler named javac but it
does not find gcj. I'm not sure who exactly to blame
40 matches
Mail list logo
