Source: gcc-12
Version: 12.3.0-15
gcc-12 is BD-Uninstallable on m68k due to missing gnat-11
but gnat-12 is present and could probably be used, at least
in a “gnat-11 | gnat-12” alternative dependency maybe?
On Sat, 16 Mar 2024, Matthias Klose wrote:
> you can work-around that by omitting -fzero-call-used-regs=used
Thanks! That will help with the transition.
Will you hand this over to upstream for an eventual fix?
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Matthias Klose dixit:
> you can work around it
Unfortunately not. (The musl packagers might be able to.)
>, this is not an RC issue. Please stop playing
> bug ping pong.
If GCC stops supporting an option it used to support,
and where the GCC documentation say it’s supported,
it in my opinion
Control: severity -1 serious
thanks
Matthias Klose dixit:
> musl is not part of the standard toolchain, not even on mips64el.
> Please build your package with the default toolchain
This isn’t (just) an issue with a package build.
This bug manifests as follows:
As a user, I install musl-tools
reassign 1050429 gcc-13 13.2.0-2
notfound 1050429 12.3.0-8
affects 1050429 musl-tools
thanks
Dixi quod…
>The -EL is not even musl-specific?!
>
>(sid_mips64el-dchroot)tg@eller:~$ cat
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
[…]
Worse, doing mips64el-linux-gnuabi64-gcc{,-12} -dumpspecs and
Dixi quod…
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
>mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL'
Dixi quod…
>According to upstream documentation, -EL is supposed to be supported
>by the compiler driver:
OK so it’s not the compiler *driver*…
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs
Hm.
According to upstream documentation, -EL is supposed to be supported
by the compiler driver:
https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html
bye,
//mirabilos
--
"Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you
Dixi quod…
>Package: gcc-13
>Version: 13.2.0-1
This is a regression against gcc-12 (= 12.3.0-8); if I install that
and export CC='diet -Os gcc-12' it works.
>./mksh -c 'x=q; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo .$x.'
In case this is relevant: that codepath uses setjmp/longjmp
Package: gcc-13
Version: 13.2.0-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I've got miscompiles of mksh with gcc-13 on x32 with dietlibc.
I could reproduce this in a chroot by doing…
export CC='diet -Os gcc'
export CFLAGS='-g -Wformat -Werror=format-security -Wall -Wextra'
export
Package: musl-tools
Version: 1.2.3-1
Severity: serious
Justification: unusable on release architectures
X-Debbugs-Cc: t...@mirbsd.de, debian-gcc@lists.debian.org
Control: affects -1 src:mksh
Unsure if it’s musl or gcc-13_13.2.0-2 but building a simple
test program fails on both mips64el and
You probably didn’t get this as debbugs fails on d-ports-only
binary packages:
-- Forwarded message --
From: Thorsten Glaser
Message-ID:
To: sub...@bugs.debian.org
Date: Thu, 21 Jan 2021 21:27:37 + (UTC)
Subject: libgcc-s2: file overwrite conflict with libgcc2
Package
On Sun, 27 Oct 2019, Debian Bug Tracking System wrote:
> #943393: gcc-9-cross: FTBFS: libatomic.so.1, needed by ./libgnat-9.so, not
> found
>
> It has been closed by Matthias Klose .
> * Link libgnatvsn against libatomic.
>
Package: libgcc-9-dev-sparc64-cross
Version: 9.2.1-8cross1
Severity: important
Tags: ftbfs
Justification: keeps src:binutils in BD-Uninstallable
Dependency installability problem for [154]binutils on x32:
Source: gcc-9-cross
Version: 12
With gcc-9-source (= 9.2.1-12), it still fails:
[…]
/usr/arm-linux-gnueabi/bin/ld: warning: libatomic.so.1, needed by
./libgnat-9.so, not found (try using -rpath or
-rpath-link)
Control: reassign -1 src:gcc-9-cross
Control: found -1 12
On Thu, 10 Oct 2019, Matthias Klose wrote:
> Control: severity -1 important
> Control: reassign -1 src:gcc-9-cross-ports
No, this is wrong. It may fail in src:gcc-9-cross-ports (= 10)
as well (which it does according to
Source: gcc-9-cross
Version: 12
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
x86_64-linux-gnux32-g++-9 -fno-PIE -c -g -I-I../../src/gcc/gm2 -Igm2
-I../../src/gcc/gm2/gm2-gcc -Igm2/gm2-gcc -g -O2 -DIN_GCC
Package: gcc-doc-base
Version: 8.3.0-1
Severity: important
Please bump gcc-doc-base to follow GCC 9, as gcc-defaults
has just done. Thanks!
-- System Information:
Debian Release: bullseye/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'),
Dear porters, could you please…
Matthias Klose dixit:
>Control: tags -1 + moreinfo
>
>please add the preprocessed source.
… because I’ve just seen this fail in the buildd QA.
Thanks,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Package: g++-8
Version: 8.3.0-7
https://buildd.debian.org/status/fetch.php?pkg=musescore-snapshot=riscv64=3.1%2Bdfsg1-1=1559616036=0
Excerpt:
[…]
make[4]: Entering directory '/<>/obj-riscv64-linux-gnu'
[ 86%] Building CXX object
found 904018 8.3.0-2
thanks
https://buildd.debian.org/status/fetch.php?pkg=gcc-8=x32=8.3.0-2=1551277939=0
I’ve again uploaded a “nocheck” build, to let the game continue,
but this ought to be eventually fixed.
Thanks,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a
Source: gcc-8
Version: 8.2.0-14
Severity: wishlist
Should it not be enough to provide it on hppa and _one_
not-ports architecture (either i386 or amd64)?
Dixi quod…
> but, at that point, 06-check-stamp was already written.
>
> Then, it hangs again.
Incidentally, killing it starts my cowbuilder hook which opens
up a shell in that chroot; at that point, build-arch was fully
done, which allowed a manual call to binary-arch to succeed (I
am going to
On Wed, 18 Jul 2018, Thorsten Glaser wrote:
> A system state inspection at the fail point shows an idle system
> and a hang here:
>
> tglase@tglase:~ $ ps axwww -O ppid | fgrep 18365
> 17623 18365 Z pts/600:00:00 [sh]
> 18365 18342 S pts/600:00:00 expect -- /usr/share/d
James Clarke dixit:
>As far as I can tell, no progress has been made on this issue since the
>few discussions on debian-devel[0]. The current state is not desirable,
I agree. I think everyone agreed that GCC should handle hardening
and dpkg should not pass the -specs= stuff any longer.
>and in
On Thu, 1 Dec 2016, Matthias Klose wrote:
> cool, thanks! bonus questions:
>
> - does the test pass with -O1, if yes can you identify
>the -O2 -fno-* flag?
> - do the above with -O0
I’ll have to try, but I’m a bit out of time for the next
two to three days.
> - do you get warnings when
On Thu, 1 Dec 2016, Thorsten Glaser wrote:
> OK. I’ve got it cut down, both regular and preprocessed
> versions are attached.
Attaching the .s output of the stripped-down version, both
unmodified and with the printf command changed. The diff
between them is not trivial, though.
bye,
//mir
tags 846214 - moreinfo
thanks
On Thu, 1 Dec 2016, Matthias Klose wrote:
> - please could you reduce the test case to just run the failing test?
I’ll try…
> - please add the preprocessed source
Attached from the following command:
gcc -DHAVE_CONFIG_H -I. -include ./config.h -I./protobuf-c
Package: gcc-6
Version: 6.2.1-5
Severity: important
The protobuf-c testsuite fails. More specifically, the attached
test-generated-code2.c file fails with the following output:
-begin output of unmodified code-
(pbuild3910)root@tglase:/tmp/buildd/protobuf-c-1.2.1 # make
Guillem Jover dixit:
>> Yes, but they *do* break anything that
>> - acts on the CFLAGS (and LDFLAGS) variables
>> - uses klcc or other compiler wrappers that don't understand -specs
>> - uses clang or pcc or whatever other compilers
>
>The default dpkg build flags have always been tied to the
clone 845193 -1
reassign -1 dpkg
retitle -1 dpkg: please do not add -specs= flags only on some architectures
thanks
Guillem Jover dixit:
>> I cannot build openssl1.0 any longer. Downgrading all binary
>> packages from src:dpkg to 1.18.10 makes the build succeed.
Interestingly enough,
Bálint Réczey dixit:
>AFAIK the linux package is the only problematic package were the
>maintainer refused to disable PIE from packaging scripts.
So, how are you supposed to do that now, instead of filtering
-fPIE from CFLAGS and -pie from LDFLAGS?
Christian/zumbi: do you take care of dietlibc,
Adrian Bunk dixit:
>gcc-6 6.2.0-7 uploaded to unstable on Tue 18 Oct 2016 defaults to PIE,
>see #835148 for details.
Oh, thanks.
This is *so* *totally* the wrong approach, especially as we
have dpkg-buildflags, which was introduced *precisely* for
this purpose, and to make Debian’s GCC not
severity 794778 important
forcemerge 833505 794778
thanks
Hi,
can we *please* have the gcc-doc source package track gcc-defaults
more closely, especially considering that the gcc-X.Y-doc packages
are already there and it’s only updating the metapackage left…
Thanks,
//mirabilos
--
tarent
Package: gcc-doc
Version: 5:4.9.2-1
Severity: important
Hi,
please update gcc-doc so it points to the documentation
for the version of GCC that’s to be released as the
default compiler for stretch.
Thanks!
-- System Information:
Debian Release: stretch/sid
APT prefers unreleased
APT
Package: gcc-4.9
Version: 4.9.2-10
Severity: minor
With the attached file, or really any program (e.g. src:pax):
1$ gcc -O2 -g -fPIE -fstack-protector-strong -flto=jobserver -c bottles.c
2$ gcc -O2 -g -fPIE -fstack-protector-strong -flto=jobserver -o x1 bottles.o
3$ gcc -O2 -g -fPIE
(excluding d-release for what they hatingly call “debian-ports spam”)
Matthias Klose dixit:
I would like to see some partial test rebuilds (like buildd or minimal chroot
Haven’t tried yet, but Helmut Grohne does automated rebootstrapping of
some ports using what he can get his hands on, and he
can’t quickly make into
buildds, so cowbuilder it is).
Debian Ports Archive Maintainer dixit:
Maintainer: Thorsten Glaser t...@mirbsd.de
Uploader: Thorsten Glaser (no PGP/MIME please, use Inline OpenPGP instead)
t...@mirbsd.org
Host: leda.debian.net
Accepted: gcc-4.9_4.9-20140109-1_m68k.changes
Package: gcc-doc
Version: 5:4.8.0-1
Severity: normal
Hi,
after upgrading gcc-doc (with gcc-4.8-doc installed) and autoremoving
gcc-4.7-doc, “info gcc” no longer works:
「Unable to find node referenced by `gcc-4.7' in `(dir)Top'.」
I think you missed one place where the outdated gcc-4.7-doc is
Matthias Klose dixit:
I think, setting the flag for the option to 0 as the default, and
applying this for m68k only would be the second best option, provided
Right…
that you cannot find out how to implement Mikael's suggestion.
… but I think I know, generally, how to do that.
(Have been
Hi!
Despite mentioning PR52306 in the changelog (as I did)
you seem to have rejected pr52306-retry-hack.diff which
is a bit unfortunate as we really need a workaround for
that ICE to build some things in the archive, e.g. Qt4,
Qt5 and anything using it, mcabber, etc.
Do you outright reject this
Matthias Klose dixit:
Which of these are applied upstream, and if not, why?
libffi-m68k.diff is applied.
m68k-revert-pr45144.diff is not applied upstream yet,
maybe Mikael knows why?
pr49847.diff is not applied yet even though it seems
to be clear – I’ve prodded them again a month ago
and have
tags 711558 - patch
thanks
It turns out we need to port more of the gcc-4.6 patches to
gcc-4.8 since we otherwise still hit some of the ICEs and
other bugs.
I’ll supply an updated debdiff soon (takes five days or so
to compile GCC, though).
bye,
//mirabilos
--
I believe no one can invent an
for pr52306 (from Mikael Pettersson)
+
+ -- Thorsten Glaser t...@mirbsd.de Sat, 17 Aug 2013 21:08:30 +0200
+
+gcc-4.8 (4.8.1-9+m68k.1) unreleased; urgency=high
+
+ * Merge several old m68k-specific patches from gcc-4.6 package:
+- libffi-m68k: rebased against gcc-4.8 and libffi 3.0.13-4
ping?
//mirabilos
--
[16:04:33] bkix: veni vidi violini
[16:04:45] bkix: ich kam, sah und vergeigte...
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Package: gcc-4.8
Version: 4.8.1-8
Severity: important
https://bugzilla.redhat.com/show_bug.cgi?id=922974
is now entering Debian, much to my joy (not).
Building mksh with “sh mksh/Build.sh -r -g -c lto”
(the “-c lto” is the trigger) lets the “link” not
succeed but instead busy-spin.
-- System
tags 711558 + patch
thanks
Hi,
please apply this one, the failure in interpret.cc is gone,
and we apparently had a patch for this in 4.6 already.
gcc-4.8 (4.8.1-7+m68k.1) unreleased; urgency=low
* Apply patch from Mikael Pettersson to fix PR49847. (Closes: #711558)
-- Thorsten Glaser t
Source: gcc-4.8
Version: 4.8.0-6
Severity: important
Tags: patch
Hi,
src:gcc-4.8 FTBFS on m68k because it fails to apply patches:
[…]
Applying patch gcc-d-lang.diff
patching file src/gcc/d/lang-specs.h
patching file src/gcc/d/lang.opt
Applying patch m68k-ada.diff
patching file
Dixi quod…
libffi_3.0.12~rc1.orig.tar.gz/utar://libffi-3.0.12-rc1/testsuite/libffi.call/a.out
The RC built fine on m68k with only a small delta
in the symbols file by the way, thanks!
bye,
//mirabilos
--
hecker cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht
To be precise:
http://gcc.gnu.org/viewcvs/trunk/gcc/regrename.c?r1=195288r2=195287view=patchpathrev=195288
That’s all we need ;-)
Thanks,
//mirabilos
--
„nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist
eine Plattform für Einzelkämpfer“
-- dieses Zitat ist ein
tags 698380 + patch fixed-upstream
thanks
mikpe at it dot uu.se dixit:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087
Mikael Pettersson mikpe at it dot uu.se changed:
--- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-01-23
21:15:40 UTC ---
(In reply to comment #0)
This
Anthony Green dixit:
Thanks - I'll look at this later today.
Thanks for merging – looking good… see attached manual-build and
test log, with reproducer script.
bye,
//mirabilos
--
ch you introduced a merge commit│mika % g rebase -i HEAD^^
mika sorry, no idea and rebasing just fscked
Hi,
here’s the updated bundle (in case the unfreeze should happen).
New: backport of three trunk changes that speed up running
genattrtab from 4-6 *hours* to roughly THREE MINUTES (on my m68k
VM, which has about 188 BogoMIPS). This is applied generally,
as the GCC developers consider it safe.
so.From 9dd3345b2ef98b1fc18a1381cfe46b0381d71777 Mon Sep 17 00:00:00 2001
From: Thorsten Glaser t...@mirbsd.org
Date: Sun, 2 Dec 2012 20:11:37 +
Subject: [PATCH] Fix 8-bit and 16-bit signed calls on m68k
Note: return_sc only tests 8-bit calls; I wrote myself a small
return_ss testcase which
- Copyright (c) 1998, 2012 Andreas Schwab
Copyright (c) 2008 Red Hat, Inc.
+ Copyright (c) 2012 Thorsten Glaser
m68k Foreign Function Interface
@@ -153,8 +154,22 @@ retstruct1:
retstruct2:
btst#7,%d2
- jbeqnoretval
+ jbeqretsint8
Package: gcc-snapshot
Version: 20121116-1
Severity: serious
Justification: uninstallable
tg@zigo:~ $ sudo apt-get --purge dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Starting
Starting 2
Investigating (0) gcc-snapshot
Matthias Klose dixit:
I'll propose 4.7.2-4 for testing, so please update.
OK thanks for the heads-up, will do after I get over
the worst of this cold I caught.
However I couldn't find the upstream GCC issue.
Didn’t report one yet, had too much dayjob-related
stuff to do this week. Will do.
Matthias Klose dixit:
how does gcc-snapshot behave?
It also introduces this failure.
If you think it's a regression, please could you forward it upstream?
OK. In the meantime, I’ve prepared workarounds upstream (and
made the code a bit less depending on -fwrapv), but I need to
know whether I
Hi,
https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1058035
was just the beginning, as gcc-snapshot in Debian had it (I
wrote that in the bugreport already), but, now, gcc-4.{6,7}
in sid also have it.
I’ve just tracked it down for gcc-4.6 to have been introdu‐
ced between 4.6.3-9 and
Package: gcc-4.7-base
Version: 4.7.2-1
Severity: serious
I don’t quite can believe this. What the hey are you doing with
your binary packages you officially upload to Debian, to get THIS?
Fetched 187 MB in 49s (3766 kB/s)
Reading changelogs...
Extracting templates from packages: 100%
(Reading
Philipp Kern dixit:
I think you could work on your politeness and adjust the tone of your
mails.
Right. I know that formulating is not one of my better skills.
I don't think Matthias had an malicious intent here, to hurt you and
induce suffering.
Yes, of course not.
I think it was merely a
Matthias Klose dixit:
-nostdlib doesn't say anything about discarding the -L flags. Did this change
with 4.7?
Hm, actually, it doesn’t.
What’s the option to do so, then? I have always been under the
impression that -nostdlib would include this behaviour.
bye,
//mirabilos
--
gcc ncal.c: In
Package: gcc-4.7
Version: 4.7.0-12
Severity: serious
Justification: breaks unrelated software
The following scenario is broken: I would expect the link to fail.
This is a carefully nailed-down testcase to figure out that the
fault is with gcc not binutils.
tg@zigo:~ $ echo 'int login_tty(int);
Matthias Klose dixit:
GCC 4.7 is now the default for x86 architectures for all frontends except the D
frontends, including KFreeBSD and the Hurd.
How are the plans for other architectures?
The m68k status (which obviously can’t influence the release decisions)
is as follows: gcc-4.7 builds,
Package: gcc-4.7-base
Version: 4.7.0-5
Severity: serious
Hi,
trying to upgrade my system breaks the package database, to a
point I have to uninstall all :i386 packages from the amd64
system… using dpkg, as apt goes on a strike.
tg@zigo:~ $ sudo apt-get --purge dist-upgrade
Reading package
+
+ -- Thorsten Glaser t...@mirbsd.de Mon, 27 Feb 2012 19:55:10 +
+
gcc-4.6 (4.6.2-16) unstable; urgency=medium
* Update to SVN 20120223 (r184520) from the gcc-4_6-branch (4.6.3 release
only in patch2:
unchanged:
--- gcc-4.6-4.6.2.orig/debian/patches/pr47612.diff
+++ gcc-4.6-4.6.2/debian/patches
forwarded 658050 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383
thanks
I’ve taken the time to track this down a little and forwarded
it upstream.
bye,
//mirabilos
--
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and
2011-10-12 19:46:01.0 +
+++ libffi-3.0.11~rc1/debian/changelog 2012-02-24 18:29:49.0 +
@@ -1,3 +1,9 @@
+libffi (3.0.11~rc1-5+m68k.1) local; urgency=low
+
+ * Fix m68k floats (Andreas Schwab) and err_bad_abi (Alan Hourihane).
+
+ -- Thorsten Glaser t...@mirbsd.de Fri, 24 Feb
/changelog
@@ -1,3 +1,15 @@
+libffi (3.0.10-3+m68k.2) unreleased; urgency=low
+
+ * Apply patch from Alan Hourihane to fix err_bad_abi testcase on m68k.
+
+ -- Thorsten Glaser t...@mirbsd.de Mon, 16 Jan 2012 17:23:35 +
+
+libffi (3.0.10-3+m68k.1) unreleased; urgency=low
+
+ * Apply patch from
Hi,
just found http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
by almost-accident (in the MiNT patch for gcc). It does not
seem to have been applied to the 4.6 branch yet; the MiNT
patch is against 4.6 and contains this.
I will test the patch from that PR in a local build and see
whether it
Comment #11 on the forwarded bug:
Andreas Schwab 2012-01-23 13:05:35 UTC
After r183426 this is now dormant on the 4.6 branch again.
On the other hand, it happens on 4.7/trunk now. But it’s
been brought to upstream’s attention, and with the next
regular 4.6 branch pull we should get this
Hi,
nevermind (close if you want), gcc-4.6 builds a cross-compiler
just fine, and since m68k was switched there anyway (looking
good so far) I’m building that now instead.
gn8,
//mirabilos
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming
Hi,
what’s the status on this? I’m considering an NMU if this
does not get fixed some time soon.
(Thanks Héctor for validating the backport.)
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste
Source: gcc-4.6
Severity: minor
(@Bernhard: /dpkg-shlibdeps: warning: dependency on.*could be
avoided.*uselessly linked/)
I’ve just spotted this in the build logs:
dpkg-shlibdeps: warning: dependency on libgcc_s.so.1 could be avoided if
debian/mksh/bin/mksh were not uselessly linked against
fixed 647553 4.6.2-3
close 647553
thanks
[…]
gcc -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Wformat-security -Werror=format-security -Wall -Wextra -fno-strict-aliasing
-fstack-protector-all -fwrapv -flto=jobserver -std=gnu99 -fPIE -pie
-Wl,-z,relro -Wl,-z,now
Package: gcc-4.6
Version: 4.6.1-13
Severity: important
Currently, compiling mksh with hardening enabled breaks on sparc (debian)
and sparc64 (debian-ports) with identical problems. I tracked this down to
the use of PIE in the final link (not object file generation) in combina-
tion with LTO using
Hi,
probably the same problem, on armel instead:
Debian buildds dixit:
* Source package: mksh
* Version: 40.2-3
* Architecture: armel
* State: failed
* Suite: sid
* Builder: antheil.debian.org
* Build log:
tags 640035 + patch
thanks
Dixi quod…
Related to #638603 even the latest version of gcj-4.4 also FTBFS.
The patch works. Uploading to d-p.org “unreleased” now.
Please include it in the next upload.
bye,
//mirabilos
--
15:39⎜«mika:#grml» mira|AO: mit XFree86® wär’ das nicht passiert - muhaha
Hi,
the patch I sent (4.4.6-10+m68k.1) indeed works for gcc-4.4 at least.
bye,
//mirabilos
--
Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL.
-- Henry Nelson, March
--- debian/libffi5.symbols.m68k (libffi5_3.0.10~rc10-3_m68k)
+++ dpkg-gensymbols3DQGiB 2011-09-03 21:23:05.0 +
@@ -14,6 +14,7 @@
ffi_prep_args@Base 3.0.4
ffi_prep_cif@Base 3.0.4
ffi_prep_cif_machdep@Base 3.0.4
+ ffi_prep_cif_var@Base 3.0.10~rc10-3
ffi_prep_closure@Base
/changelog
@@ -1,3 +1,10 @@
+gcc-4.4 (4.4.6-10+m68k.1) unreleased; urgency=low
+
+ * [m68k] Disable multilib, it FTBFS. (Closes: #638603)
+ * debian/patches/pr47908.diff: Fix ICE on m68k. (Closes: #635918)
+
+ -- Thorsten Glaser t...@mirbsd.de Thu, 01 Sep 2011 20:31:52 +
+
gcc-4.4 (4.4.6-10
Hi,
when I looked at this at Debconf 11, I copied two functions from the
Linux or FreeBSD (don’t remember, used the one that looked more fitting)
file over. The exact diff I sent to Christoph Egger, don’t have it with
me any more.
Christoph, can you send the patch here for difference? It differs
Ludovic Brenta dixit:
I've already uploaded (yesterday evening) with my proposed patch but if
your patch is better, I'll be happy to upload with yours.
Yes, I noticed because of the upload (keeping an eye on d-d-changes
at the moment). I don’t know whether my patch is better, with Ada
it’s
Source: gcc-4.4
Hi,
please add the fix for PR/47908 from:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=24863action=diff
The fix is scheduled for upstream inclusion, only waiting for
the FSF to process the copyright assignment papers, so it should
be fine.
bye,
//mirabilos
--
Using Lynx is
Source: gcc-4.6
Hi,
please add the fix for PR/47908 from:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02514.html
The fix is scheduled for upstream inclusion, only waiting for
the FSF to process the copyright assignment papers, so it should
be fine.
bye,
//mirabilos
--
Sometimes they [people]
Richard dixit:
what is prev_insn?
(gdb) print prev_insn
No symbol prev_insn in current context.
Maybe this?
(gdb) print previous_insn
$4 = {rtx (rtx)} 0x801182c4 previous_insn
(gdb) print prev_real_insn
$6 = {rtx (rtx)} 0x801184b4 prev_real_insn
(gdb) print prev_active_insn
$7 = {rtx (rtx)}
Source: gcj-4.6
Version: 4.6.1-2
Severity: serious
Justification: fails to build from source
Building (bootstrapping) gcj-4.6 fails after 3/4 days at:
/bin/bash ./libtool --tag=GCJ --mode=compile
/tmp/buildd/gcj-4.6-4.6.1/build/./gcc/gcj
Adam D. Barratt dixit:
This isn't RC. It's not a regression, and m68k isn't a release architecture in
any case.
Sure. I just selected FTBFS severity in reportbug,
but don’t disagree with that.
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much*
Source: gcc-defaults
Version: 1.106
Three things I noticed in 1.105 which were not yet fixed
in 1.106 – the second one must be addressed in another
upload before I can build this on m68k; the third one is
an FTBFS fix I could work around (but since we require
an upload due to the second issue
Thorsten Glaser dixit:
So this is at least not
worse than the current state, and please include it in the next
upload.
Well, it built, and I uploaded it to debian-ports.org unreleased,
so please, everyone who can, test it.
+ 158 Jul 4 Debian Ports Archive Maintai (2174)
gcc-4.6_4.6.1-1
)
--- gcc-4.6-4.6.1/debian/changelog
+++ gcc-4.6-4.6.1/debian/changelog
@@ -1,3 +1,15 @@
+gcc-4.6 (4.6.1-1+m68k.1) unreleased; urgency=low
+
+ [ Thorsten Glaser ]
+ * Apply changes from src:gcc-4.4 for m68k support:
+- debian/rules.defs: Remove m68k from locale_no_cpus.
+- debian/patches/gcc
changed) please tell me./* Copyright (c) Thorsten Glaser. Part of mksh, under the MirOS Licence. */
#include err.h
#include stddef.h
#include stdint.h
#include stdio.h
#include stdlib.h
#include string.h
#define BIT(i) (1 (i)) /* define bit in flag */
#define DEFINED BIT(1
Matthias Klose dixit:
At this point, pretty well after the GCC 4.6.0 release, I would like to avoid
switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce
maintenance efforts on the debian-gcc side, even before the multiarch changes
Porters side, too. I’m okay with
Hi,
pr43804.diff (in src:gcc-4.4 in Debian) has been committed as-is
upstream and needs to be applied to at least gcc-4.5 and gcc-4.6
bye,
//mirabilos
--
13:47⎜tobiasu if i were omnipotent, i would divide by zero
all day long ;)
(thinking about
Michael Tomkins dixit:
make[2]: Entering directory `/usr/src/mpc-0.9/tests'
We build with cowbuilder from Debian source packages, never
there manually.
On 03/03/2011, at 6:35 AM, Thorsten Glaser wrote:
dependencies, we �just� got gcc-4.4 in a pretty good shape,
plus it�s used by the kernel
Matthias Klose dixit:
- removed on 2010-06-16 in the gcc-4.4 branch by doko (rev 4510), or
It was removed.
- it is still present however in the gcc-4.5 and gcc-4.6 branches, where
The m68k support came rather late during gcc-4.4 development,
since that was what was in unstable at that time,
Brian Morris dixit:
I noticed the other day that a new dependency (MPC) from upstream for gcc4.5
http://gcc.gnu.org/gcc-4.5/changes.html
is failing to build on 68k,
see m68k at the bottom of this page, says not since gcc 4.3.
While I can probably take care of compiling gcc-4.5 and its
I uploaded gcc-4.4 4.4.5-8 to unstable, works fine so far.
I’ve also made a gcj-4.4 package for unreleased out of it,
following the documentation, which also seems to work well
(once build-deps are installed).
So, all that’s left is probably:
• look at the symbols warnings from Message #30
•
cannot reproduce with 4.4.5-8
//mirabilos
--
20:54⎜SvenG:#grml dmaphy: remember: In theory there's no difference
⎜ between theory and practice, but in practice...
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Source: gcj-4.4
Version: 4.4.5-2
Severity: important
While compiling gcc-4.4_4.4.5-8 as gcj-4.4_4.4.5-2+m68k.1 I noticed,
and confirmed by looking at buildd logs of gcj-4.4_4.4.5-2 that it’s
not a local problem, that GCC not only contains an embedded code copy
of libz but also compiles it (at
1 - 100 of 116 matches
Mail list logo
