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 ve
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 i
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'
>(sid_mips64el-d
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
"/usr/
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 feel
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 qu
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 CPPFLAGS='
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 mipsel
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
https://buildd.de
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
-DCROSS_DIRECTORY_STRUCT
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&arch=riscv64&ver=3.1%2Bdfsg1-1&stamp=1559616036&raw=0
Excerpt:
[…]
make[4]: Entering directory '/<>/obj-riscv64-linux-gnu'
[ 86%] Building CXX object
mtest/zerberus/inputControls/CMakeFiles/tst_sfz
found 904018 8.3.0-2
thanks
https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=x32&ver=8.3.0-2&stamp=1551277939&raw=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 eventua
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 u
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 f
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 y
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
t/generated-code2
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 spec
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, src:openssl
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 incom
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 soluti
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 policy:
reopen 78
thanks
Debian Bug Tracking System dixit:
>Their explanation is attached below along with your original report.
>If this explanation is unsatisfactory and you have not received a
>better one in a separate message then please contact Eduard Bloch
> by
>replying to this email.
This i
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 -fstack-prot
(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
got machines I can’t quickly make into
buildds, so cowbuilder it is).
Debian Ports Archive Maintainer dixit:
>Maintainer: Thorsten Glaser
>Uploader: Thorsten Glaser (no PGP/MIME please, use Inline OpenPGP instead)
>
>Host: leda.debian.net
>Accepted: gcc-4.9_4.9-20140109-1_m6
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
ref
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 deal
Matthias Klose dixit:
>yes, I do reject this.
I see. Would you please…
>> “for the time being”? If so, would you accept a patch
>> that just disables -fauto-inc-dec on m68k *always*,
>> even in the cases where it doesn’t ICE? (one-liner)
answer whether this would be considerable? (Untested,
but
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 p
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
w
+
+ * Use -fno-auto-inc-dec for pr52306 (from Mikael Pettersson)
+
+ -- Thorsten Glaser 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
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 alg
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:
http://lists.debian.org/pine.bsm.4.
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 Inf
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 Fri
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 src/gcc/ada/gcc-i
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
--
cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Ja
To be precise:
http://gcc.gnu.org/viewcvs/trunk/gcc/regrename.c?r1=195288&r2=195287&view=patch&pathrev=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 changed:
>--- Comment #2 from Mikael Pettersson 2013-01-23
>21:15:40 UTC ---
>(In reply to comment #0)
>This sounds a lot like PR52573, a patch was pr
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
--
you introduced a merge commit│ % g rebase -i HEAD^^
sorry, no idea and rebasing just fscked │ Segmentati
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.
Al
endif
--- a/src/libffi/src/m68k/sysv.S
+++ b/src/libffi/src/m68k/sysv.S
@@ -2,6 +2,7 @@
sysv.S - Copyright (c) 1998, 2012 Andreas Schwab
Copyright (c) 2008 Red Hat, Inc.
+ Copyright (c) 2012 Thorsten Glaser
m68k Foreign Function Interface
@@ -153,8
too. Dursleys' continued existence indicates so.From 9dd3345b2ef98b1fc18a1381cfe46b0381d71777 Mon Sep 17 00:00:00 2001
From: Thorsten Glaser
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 smal
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.
b
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 4.6.3-10
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
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 dat
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
--
ncal.c: In funct
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); vo
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, la
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 lists.
Source: gcc-4.6
Severity: wishlist
Hi,
while https://wiki.debian.org/BuildingCrossCompilers is an
invaluable help to people dabbling in such black art, but
wishing to do it “the proper Debian way”, it lacks a certain
functionality.
For example, if I want to build a cross-compiler to Debian/m68k,
err_bad_abi (Alan Hourihane).
+
+ -- Thorsten Glaser Sun, 04 Mar 2012 15:40:20 +
+
libffi (3.0.11~rc1-5) experimental; urgency=low
* Fix powerpc and ppc64 builds (Kyle Moffett).
diff -Nru libffi-3.0.11~rc1/debian/patches/m68k-fix.diff
libffi-3.0.11~rc1/debian/patches/m68k-fix.diff
--- libffi
+
+ -- Thorsten Glaser 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/pr47612.diff
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⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
hangelog 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 Fri, 24 Feb 20
hangelog
+++ libffi-3.0.10/debian/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 Mon, 16 Jan 2012 17:23:35 +
+
+libffi (3.0.10-3+m68k.1) unreleased; urgency=low
+
+
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 fix
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 workable
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 pool
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 beide
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 -fuse-linke
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:
> https://buildd.debian.org/fetch.cgi?pkg=mksh&arch=armel&ver=40.2-3&stamp=
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
--- 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 3.0
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, Marc
4.6/debian/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 Thu, 01 Sep 2011 20:31:52 +
+
gcc-4.4 (4.4.6-10) unstable; u
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 real
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
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]
Source: gcc-4.4
Hi,
please add the fix for PR/47908 from:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=24863&action=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
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
(gdb) print prev_real_insn
$6 = {rtx (rtx)} 0x801184b4
(gdb) print prev_active_insn
$7 = {rtx (rtx)} 0x801185ac
(gdb) print p
Richard dixit:
>equiv_constant is called with NULL pointer, I would think this is
>illegal and the problem happened one level up :
Probably.
(gdb) frame 1
#1 0x804b0542 in fold_rtx (x=0xc83cb5f4, insn=0xc83cc1c0) at
../../src/gcc/cse.c:3274
3274const_arg = equiv_constant (folde
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: 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
-B/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040
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 anyw
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.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-multiarch.diff: Add m68k multiarch_mappings
ction changed) please tell me./* Copyright (c) Thorsten Glaser. Part of mksh, under the MirOS Licence. */
#include
#include
#include
#include
#include
#include
#define BIT(i) (1 << (i)) /* define bit in flag */
#define DEFINED BIT(1) /* is defined in block */
#de
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 kee
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⎜ if i were omnipotent, i would divide by zero
all day long ;)
(thinking about http://lobacevski.tumblr.com/post/32608664
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,
>>
1 - 100 of 121 matches
Mail list logo
