Package: gcc-4.6
Version: 4.6.3-1
Severity: wishlist
Dear gcc maintainers,
Motivation
~~
I would like to install ghc:i386 and gcc:amd64. Currently this is not
possible, because ghc depends on gcc and gcc is not multiarch:foreign
(which is correct of course). So can this work at all? I
On Mon, Apr 02, 2012 at 10:09:52AM +0200, Matthias Klose wrote:
tags 666743 + wontfix
thanks
Did you forget to cc control@?
looks like an april fool joke. If not, then it's won't fix. upstream
did explicitly remove the ability to specify the triplet/target and
the version from the driver.
Package: gcc-4.7-multilib
Version: 4.7.0-1
Severity: normal
Dear gcc maintainer,
Since version 4.7 gcc is able to produce x32 binaries. Unfortunately
this feature is not currently usable in Debian sid.
$ cat true.c
int main(void) { return 0; }
$ gcc-4.7 true.c # everything works
$ gcc-4.7 -m32
On Tue, Apr 03, 2012 at 03:06:13PM +0200, Matthias Klose wrote:
severity 667005 wishlist
clone 667005 -1
reassign -1 src:eglibc
retitle -1 build eglibc for x32
thanks
Did you forget to cc control@ again? But wait before resending.
On 03.04.2012 12:43, Helmut Grohne wrote:
then please
Package: src:gcc-4.8
Version: 4.8.2-17
Severity: normal
Tags: patch
When building a cross compiler DEB_CROSS_NO_BIARCH=yes is ignored if
DEB_TARGET_ARCH=x32. In other words, it becomes a multilib build even
though a non-multilib build was requested. The attached patch solves the
issue for me.
Package: src:gcc-4.8
Version: 4.8.2-17
Severity: normal
Tags: patch
When building a non-multilib stage1 cross compiler targeting x32, an
amd64 compiler is built instead. The attached patch takes care to add
the missing --with-abi flag for this situation.
Helmut
diff -u
mudflap from cross-install-location.diff since mudflap was removed
+from gcc 4.9. Closes: #742606
+
+ -- Helmut Grohne hel...@subdivi.de Wed, 26 Mar 2014 19:18:38 +0100
+
gcc-4.9 (4.9-20140322-1) experimental; urgency=medium
* Package GCC 4.9 snapshot 20140322.
diff -u gcc-4.9-4.9
Package: gcc-4.8
Version: 4.8.2-18
Severity: minor
Tags: patch
Hi doko,
gcc-4.8 also defaults to --enable-multilib on sparc64. So it needs to be
explicitly disabled there for DEB_CROSS_NO_BIARCH. Patch attached.
Thanks
Helmut
diff -u gcc-4.8-4.8.2/debian/rules2 gcc-4.8-4.8.2/debian/rules2
---
.
+ * Adapt context of powerpc_remove_many.diff to fix FTCBFS for powerpcspe.
+Closes: #-1.
+
+ -- Helmut Grohne hel...@subdivi.de Sat, 05 Apr 2014 17:30:17 +0200
+
gcc-4.8 (4.8.2-19) unstable; urgency=medium
* Update to SVN 20140404 (r209122) from the gcc-4_8-branch.
diff -u gcc-4.8-4.8.2/debian
Control: reopen -1
Control: found -1 4.8.2-19
You inserted a typo when you applied the following patch:
On Sat, Apr 05, 2014 at 01:48:06AM +, Debian Bug Tracking System wrote:
diff -u gcc-4.8-4.8.2/debian/rules2 gcc-4.8-4.8.2/debian/rules2
--- gcc-4.8-4.8.2/debian/rules2
+++
. Closes: #-1.
+
+ -- Helmut Grohne hel...@subdivi.de Sun, 06 Apr 2014 09:20:09 +0200
+
gcc-4.8 (4.8.2-19) unstable; urgency=medium
* Update to SVN 20140404 (r209122) from the gcc-4_8-branch.
diff -u gcc-4.8-4.8.2/debian/patches/gcc-linaro.diff
gcc-4.8-4.8.2/debian/patches/gcc-linaro.diff
patches/cross-ma-install-location.diff,
+because there is no mudflap in gcc-4.9 anymore. Closes: #-1
+
+ -- Helmut Grohne hel...@subdivi.de Sat, 12 Apr 2014 10:29:18 +0200
+
gcc-4.9 (4.9-20140411-1) unstable; urgency=medium
* GCC 4.9.0 release candidate 1.
diff -u gcc-4.9-4.9-20140411
Control: reopen -1
Control: tags -1 + pending
On Mon, Apr 07, 2014 at 04:38:09PM +0200, Matthias Klose wrote:
Am 06.04.2014 09:25, schrieb Helmut Grohne:
Package: gcc-4.8
Version: 4.8.2-19
Severity: normal
Tags: patch
Some parts of gcc-linaro.diff went into svn-updates.diff as well
.
++ Set its architecture to CROSS_ARCH if necessary.
++ Invoke dh_gencontrol with $(cross_gencontrol) if necessary.
+(Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Sun, 14 Apr 2014 18:35:08 +0200
+
gcc-4.8 (4.8.2-19) unstable; urgency=medium
* Update to SVN 20140404 (r209122
; urgency=low
+
+ * Non-maintainer upload.
+ * Enable Multi-Arch headers for cross builds that set
+with_deps_on_target_arch_pkgs=yes. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Tue, 15 Apr 2014 16:28:55 +0200
+
gcc-4.8 (4.8.2-19) unstable; urgency=medium
* Update to SVN 20140404
by not building for hppa64.
+(Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Fri, 18 Apr 2014 06:07:09 +0200
+
gcc-4.8 (4.8.2-19) unstable; urgency=medium
* Update to SVN 20140404 (r209122) from the gcc-4_8-branch.
diff -u gcc-4.8-4.8.2/debian/rules.defs gcc-4.8-4.8.2/debian/rules.defs
--- gcc
On Sat, Apr 19, 2014 at 04:43:20AM +0200, Matthias Klose wrote:
this is not biarch, but a cross compiler. So what you need to do is to make
sure
that you are able to build a canadian cross (cross-building the cross
compiler).
Just omitting to build the hppa64 cross-compiler would leave you
Control: reassign -1 binutils
Control: retitle -1 binutils-hppa64 not created for TARGET=hppa
Sorry for the confusion.
On Sat, Apr 19, 2014 at 11:52:20AM -0400, John David Anglin wrote:
The 64-bit compiler and binutils tools are required because certain PA-RISC
machines
only support 64-bit
+
+ * Non-maintainer upload.
+ * Add new libraries src/libvtv and src/libcilkrts to
+cross-ma-install-location.diff. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Sat, 19 Apr 2014 15:16:47 +0200
+
gcc-4.9 (4.9-20140411-2) unstable; urgency=medium
* Disable running the testsuite
On Mon, Apr 14, 2014 at 06:39:43PM +0200, Helmut Grohne wrote:
When cross building a gcc stage3 with_deps_on_target_arch_pkgs=yes, I
noticed that libgccX is uninstallable, because it's dependency on
gcc-4.8-base is not fulfilled (the native one rightfully isn't
M-A:foreign). I believe that gcc
On Thu, May 08, 2014 at 03:49:51PM +, Thorsten Glaser wrote:
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
Package: src:gcc-4.9
Version: 4.9.0-2
Severity: normal
User: helm...@debian.org
Usertags: rebootstrap
Hi doko,
gcc-4.9 needs a symbol update for libasan1 on sparc64:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9arch=sparc64ver=4.9.0-2stamp=1399328900
| dh_makeshlibs -plibasan1
|
gcc-powerpcspe-ldbl-fix applied upstream.
+
+ -- Helmut Grohne hel...@subdivi.de Mon, 09 Jun 2014 13:18:22 +0200
+
gcc-4.9 (4.9.0-6) unstable; urgency=medium
* Update to SVN 20140608 (r211353) from the gcc-4_9-branch.
diff -u gcc-4.9-4.9.0/debian/patches/powerpc_remove_many.diff
gcc-4.9-4.9.0
Package: src:gcc-4.9
Version: 1:4.9.0-7
Severity: normal
User: helm...@debian.org
Usertags: rebootstrap
Hi Doko,
Could you update the symbols file for sh4?
https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_sh4_gcc49/4/console
| DEB_HOST_ARCH=sh4 dh_makeshlibs -plibgcc1 -plibgcc1-dbg
Package: src:gcc-4.9
Version: 4.9.1-7
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
Currently gcc cross builds targeting mips64el with
DEB_CROSS_NOBIARCH=yes do not work in the sense that it attempts a
multilib build. Please apply the attached patch to
Package: gcc-4.9
Version: 4.9.1-19
Severity: serious
Justification: do not migrate to jessie
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
I notice that starting with -19 gcc emits unsatisfiable dependencies in
multiarch cross builds regressing from -18. This makes all rebootstrap
Control: tags -1 + patch
On Sat, Oct 25, 2014 at 05:58:36AM +0200, Helmut Grohne wrote:
I'll look into the matter and try to provide a patch.
It seems that your upload forcibly clears with_deps_on_target_arch_pkgs
and no_biarch_libs. This functionality has been working very well over
the past
Control: severity -1 serious
I am raising the severity again, because the change is obviously
hostile. It breaks working functionality without any benefit. Keep this
out of jessie.
Please revert asap or discuss this with ctte.
Helmut
--
To UNSUBSCRIBE, email to
Control: reassign -1 tech-ctte
Dear technical committee,
I ask you to overrule the gcc maintainer and rule that the following
hunks to the gcc-4.9 package must be reverted:
diff -u gcc-4.9-4.9.1/debian/rules.defs gcc-4.9-4.9.1/debian/rules.defs
--- gcc-4.9-4.9.1/debian/rules.defs
+++
On Mon, Oct 27, 2014 at 09:41:59PM +, Ian Jackson wrote:
The most obvious bug is the one mentioned in the patch: #760770
It is about a bug in the implementation of with_deps_on_target_arch (the
contended feature).
I think I may not understand what's going on here. In your mail to
-19.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Update cross-ma-install-location.diff for libphobos. Closes: #760770.
+
+ -- Helmut Grohne hel...@subdivi.de Tue, 28 Oct 2014 18:57:40 +0100
+
gcc-4.9 (4.9.1-19) unstable; urgency=medium
* GCC 4.9.2 release candidate.
diff -u gcc
On Wed, Oct 29, 2014 at 01:08:40PM +, Iain Buclaw wrote:
Is this something that should be pushed upstream too?
No, I don't think so. The with_deps_on_target_arch_pkgs option is
unsupported in the gcc package and is disabled in 4.9.1-19. The updated
cross-ma-install-location.diff actively
On Sat, Nov 01, 2014 at 01:46:48AM +, Wookey wrote:
To me that sounds like this method is actually the
current de-facto default in Debian - it is certainly at least on a par.
I don't think that a feature being de-facto default is a good argument
to force maintaining it forever. There
-compilers. Regression introduced in
| dpkg 1.17.14. Reported by Helmut Grohne hel...@subdivi.de.
It seems to me that dpkg-buildpackage --target-arch is the way to go. So
what are the reasons to keep supporting the alternatives? It seems
unlikely the proposed changes are eligible for a jessie unblock
Hi Don,
On Wed, Nov 19, 2014 at 04:41:49PM -0800, Don Armstrong wrote:
Are people who are doing cross-building like this actually using the
code which will be in jessie? I (perhaps naïvely) would expect them to
be primarily using the code in unstable, and maybe at a late stage of
bring-up
/changelog
--- gcc-4.9-4.9.2/debian/changelog
+++ gcc-4.9-4.9.2/debian/changelog
@@ -1,3 +1,10 @@
+gcc-4.9 (4.9.2-3.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Inhibit multilib libgcc dependencies in stage1. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 27 Nov 2014 23:15
On Fri, Nov 28, 2014 at 01:43:01PM +0100, Matthias Klose wrote:
gcc-4.9-multilib-$targettriplet depends on
* lib${biarch}gcc-4.9-dev
This package is not built in stage1.
this is wrong. find out why lib${biarch}gcc-4.9-dev is not built for you. it
works for me.
Thanks for insisting.
I am wondering how to cross build libgcc1 in a bootstrap setting. The
obvious answer is cross build gcc-4.9. Looking at its Build-Depends
this means that I first need to build gmp to satisfy the dependency on
libgmp-dev. Let us assume that this just works. Now libgmp-dev depends
on libgmpxx4ldbl
Package: src:gcc-4.9
Version: 4.9.2-5
User: helm...@debian.org
Usertags: rebootstrap
When building a cross compiler for mips64el (and possibly other mips
architectures), some binary packages are broken.
$ dpkg-deb -I ./libn32gcc-4.9-dev-mips64el-cross_4.9.2-5_all.deb
new debian package,
-maintainer upload.
+ * Allow target selection via dpkg-buildpackage --target-arch. Closes: #-1.
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 13 Dec 2014 22:11:40 +0100
+
gcc-4.9 (4.9.2-7) unstable; urgency=medium
* Update to SVN 20141210 (r218575) from the gcc-4_9-branch.
diff -u gcc-4.9-4.9.2
On Wed, Dec 10, 2014 at 09:54:01AM +0100, Matthias Klose wrote:
I can't remember. please ask the Debian mips maintainers. I assume, extending
the expression to entirely remove empty fields should work around this for
now.
I did X-Debbugs-Cc the submission to debian-mips@l.d.o. So now I did
/debian/changelog gcc-4.9-4.9.2/debian/changelog
--- gcc-4.9-4.9.2/debian/changelog
+++ gcc-4.9-4.9.2/debian/changelog
@@ -1,3 +1,10 @@
+gcc-4.9 (4.9.2-7.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Fix: i386 stage1 builds packages not in control. (Closes: #-1)
+
+ -- Helmut Grohne hel
Control: tags -1 - moreinfo
On Tue, Dec 16, 2014 at 01:37:12PM +0100, Matthias Klose wrote:
please verify your patch using an old dpkg from wheezy, using native builds
and
the supported cross builds and attach the four compressed build logs.
I have some problems making sense of this, please
On Tue, Dec 16, 2014 at 08:49:28AM +0100, Helmut Grohne wrote:
When building a stage1 for i386 at some point of the build, dh_something
-plibx32gcc-4.9-dev-i386-cross fails, because the named package is not
in debian/control. It should be, because on unstable x32 multilib is
enabled for i386
Control: reopen -1
Control: found -1 4.9.2-9
On Sat, Dec 20, 2014 at 01:27:19PM +, Debian Bug Tracking System wrote:
* Add x32 multilib packages for i386 cross builds to the control file.
Closes: #773265.
I suppose that you closed the wrong bug here. It is still fully
reproducible
.
+
+ -- Helmut Grohne hel...@subdivi.de Fri, 23 Jan 2015 23:22:37 +0100
+
gcc-5 (5-20150121-1) experimental; urgency=medium
* GCC 5.
diff -u gcc-5-5-20150121/debian/patches/cross-install-location.diff
gcc-5-5-20150121/debian/patches/cross-install-location.diff
--- gcc-5-5-20150121/debian
Source: gcc-4.9
Version: 4.9.1-17
User: helm...@debian.org
Usertags: rebootstrap
gcc-4.9 currently FTBFS on sparc64 due to symbol errors. While the last
two builds on sompek failed due to -ENOSPC the build of 4.9.1-17 shows
proper symbol diffs:
-20150307/debian/changelog
--- gcc-5-5-20150307/debian/changelog
+++ gcc-5-5-20150307/debian/changelog
@@ -1,3 +1,10 @@
+gcc-5 (5-20150307-1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Fix context of pr52306.diff. Closes: #-1.
+
+ -- Helmut Grohne hel...@subdivi.de Sat, 14 Mar
/changelog
@@ -1,3 +1,10 @@
+gcc-5 (5-20150321-1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Update cross-install-location for libcc1. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Sun, 22 Mar 2015 07:41:14 +0100
+
gcc-5 (5-20150321-1) experimental; urgency=medium
Source: gcc-5
Version: 5.1~rc1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Since the cxx_inc_dir removal in gcc-5, the full cross compiler build
fails:
| DH_COMPAT=2 dh_movefiles -plibstdc++-5-dev-arm64-cross usr/include/c++/5
Control: tags -1 - moreinfo
Why did you tag the bug moreinfo? It fails to build. The problem is
easily reproducible. What information are you missing?
On Fri, Apr 24, 2015 at 02:58:04PM +0200, Matthias Klose wrote:
why does it need the plugin, but not libcc1-0? Did you check that a cross gdb
Package: cpp
Version: 4:4.9.2-3
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap
The new cpp conflicts break architecture bootstrap. See for instance:
https://jenkins.debian.net/job/rebootstrap_mips_gcc5_supported/9/console
The collateral damage induced by these conflicts simply
Source: gcc-4.9
Version: 4.9.2-10
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Example failing log (of a stage2 build):
| /tmp/buildd/gcc_2/gcc-4.9-4.9.2/build/./gcc/xgcc
-B/tmp/buildd/gcc_2/gcc-4.9-4.9.2/build/./gcc/ -B/usr/powerpc64-linux-gnu/bin/
On Fri, May 01, 2015 at 02:12:11PM +0200, Matthias Klose wrote:
there is no package inside the distribution where this would break anything.
For
the bootstrap you certainly can work around this by ignoring the conflicts.
This
Since rebootstrap does not do native builds, it is non-trivial to
Hi Matthias,
cpp still has some bogus conflicts left. It seems that you forgot to
remove them when you closed this bug. Thus I reopened it. Since the mips
and mipsel cross compilers in the archive are now built standalone, I
assume that these conflicts can just be removed as well.
Helmut
--
Source: gcc-5
Version: 5.1.1-13
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Trying to build a stage1 cross compiler for kfreebsd-any, e.g.
kfreebsd-amd64 fails with the following error:
From https://jenkins.debian.net/job/rebootstrap_kfreebsd-amd64_gcc5/2/console
|
Source: gcc-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
m68k implements does not have hardware supported atomics, so it falls
back to linux syscalls to implement atomics on that architecture even
when one builds a stage1 (without libc). However the Build-Depends do
not reflect
Source: cloog
Version: 0.18.3-1
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap
I noticed that since the isl upload 0.15-3 cloog can no longer be cross built
for some (maybe all) architectures. Linking fails finding some isl symbols.
See e.g.
/debian/changelog
--- gcc-5-5.2.1/debian/changelog
+++ gcc-5-5.2.1/debian/changelog
@@ -1,3 +1,11 @@
+gcc-5 (5.2.1-22.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Support building cross compilers for architectures not covered by
+binutils-multiarch. Closes: #-1.
+
+ -- Helmut
On Wed, Nov 04, 2015 at 06:26:01AM +0100, Helmut Grohne wrote:
> | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src -D_FORTIFY_SOURCE=2
> -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes
> -Wmissing-prototypes -Wnested-externs -Wbad-function-cast
>
Control: tags -1 - patch
On Fri, Nov 13, 2015 at 12:20:14AM +0100, Matthias Klose wrote:
> - the patch is incomplete. It still calls the binutils tools
>for the host unprefixed.
Can you give an example here? If you mean that some dh_strip calls are
not prefixed, then that's intentional.
Source: gcc-5
Version: 5.2.1-26
Severity: minor
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
When building cross compilers targeting amd64, i386 or x32 by writing
the arch name to debian/target, the build process tries to build hppa64
cross compilers. This seems a bit
On Sat, Nov 28, 2015 at 02:58:31AM +0100, Matthias Klose wrote:
> No. Why would you handle hppa as a secondary or ternary architecture? You
> need the hppa64 cross compiler to bootstrap hppa. Other architectures
> require a multilib enabled compiler to bootstrap the architecture, however
>
Source: gcc-5
Version: 5.2.1-24
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
The new parallel code makes DEB_STAGE=rtlibs fail. Close to the end of
the build, I see Invocations like "dh_gencontrol -p. ...". Debhelper
doesn't like "." as a package name. I believe that
Source: gcc-6
Version: 6.1.1-6
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
can you add support for the tilegx architecture to gcc-6?
State of tilegx:
* Waiting for inclusion into dpkg: #823167
* Supported in linux-libc-dev: #824524 #823632
* Two
Package: gcc-5,gcc-6
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
Starting with dpkg 1.18.5, the parsing of Build-Depends has become
stricter. This causes dpkg-shlibdeps to error out on gcc's Build-Depends
when disabling multilib with
Source: gcc-6
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
This is my second patch for musl. This time it is about musl-linux-armhf
only. The gcc packaging has some matching logic for setting make
variables such as $(float_abi). Since they currently
Source: gcc-6
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
I've been working on bootstrapping a musl-based port for a while now and
think that some patches are sufficiently stable that they can go
upstream already. One of the obstacles here is the
Source: gcc-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
It was never possible to bootstrapp x86 architectures using gcc-6,
because stage1 and stage2 compilers were never buildable. That's due to
gcc-6 enabling libmpx by default. However, libmpx needs a working libc.
Thus the
Source: gcc-7
Version: 6.3.0-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
I started trying cross toolchain builds with gcc-7 and quickly noticed
that cross-install-location.diff hasn't been updated for gcc-7 yet. I am
attaching a patch to that minimally updates it to
Control: reopen -1
Control: reassign -1 src:gcc-6
On Tue, Sep 20, 2016 at 10:19:12PM +, Debian Bug Tracking System wrote:
> Please allow selecting the target architecture using "dpkg-buildpackage
> --target-arch" again. This ability was removed in 4.9.2-7 when #768167
> was fixed.
>
> I am
Package: libstdc++-6-dev
Version: 6.3.0-1
Severity: important
User: helm...@debian.org
Usertags: rebootstrap
An attempt at installing libstdc++-6-dev:armel fails:
| # apt-get -y install libstdc++-6-dev libstdc++-6-dev:armel
| ...
| dpkg: error processing archive
=medium
+
+ * Non-maintainer upload.
+ * Mark autoconf2.64 Multi-Arch: foreign (Closes: #-1)
+
+ -- Helmut Grohne <hel...@subdivi.de> Mon, 05 Dec 2016 20:39:56 +0100
+
autoconf2.64 (2.64+dfsg-0.1) unstable; urgency=medium
* Non-maintainer upload.
diff -u autoconf2.64-2.64+dfsg/debian/c
Source: gcc-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Building gcc libraries with DEB_STAGE=rtlibs is now successful. Yet the
resulting packages are not currently installable. See e.g.:
> Setting up gcc-7-base:tilegx (7-20170316-1) ...
> dpkg: dependency problems prevent
Source: gcc-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
trying to build gcc-7 with DEB_STAGE=rtlibs results in an error over
here. A nios2 build[1] fails with:
| DEB_HOST_ARCH=nios2 dh_gencontrol -pgcc-7-nios2-linux-gnu-base --
-v7-20170226-1
Source: gcc-7
Severity: wishlist
Tags: patch
Control: block 798955 by -1
User: helm...@debian.org
Usertags: rebootstrap
For coinstalling multiple libcs (e.g. any-gnu-any-any and
any-musl-any-any) or coinstalling glibc for different kernels (e.g.
linux-any and kfreebsd-any), it is necessary to
Source: gcc-7
Version: 7-20170221-1
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
thank you for disabling brig in stage1 and stage2. It still is rightly
enabled in the unstaged cross compiler build. Since it is not needed for
bootstrapping, I'd like to disable
Source: gcc-7
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
The multiarch stuff in gcc is still not entirely upstream and we are
carrying part of it in debian/patches/gcc-multiarch.diff. Notably
missing there is support for non-glibc architectures.
Source: gcc-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block 795432 by -1
Hi Matthias,
debhelper 10.9 fixed #795432 and that makes building a fortran cross
compiler fail.
debian/rules.d/binary-fortran.mk says:
dh_installdirs -p$(1) ...
The argument is the
Source: gcc-7
User: helm...@debian.org
Usertags: rebootstrap
Control: block 795432 by -1
Hi Matthias,
I discovered another debhelper 10.9 regression in gcc-7. In
debian/rules2, a dh_prep is passed -N$(p_hppa64) and that package is not
listed in debian/control while building DEB_STAGE=rtlibs.
Source: gcc-8,gcc-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
since debhelper 10.9.1, more specifically
https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=93d8fdfc5dfc994af53fc6fed7f36f271b3abee5
the DEB_STAGE=rtlibs build of gcc fails. Such builds
Control: tags -1 + patch
On Wed, Nov 29, 2017 at 02:33:53AM +0100, Matthias Klose wrote:
> as discussed on irc, the alternative solution should be preferred.
Ah, right. Thank you for the reminder.
In the mean time, I tried to agree on a better header name for
"X-DH-Build-For-Type: target" with
Source: gcc-8
Version: 8-20180218-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block 666743 by -1
While working on coinstallable toolchains, I deactivated biarch to speed
up initial test builds and discovered that doing so produces broken
Build-Depends. debian/control.m4
Source: gcc-7
Version: 7.3.0-27
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
I'm not sure whether you're aware already, but I felt that it was best
to just document that gcc-7 fails to build against isl 0.20. I tried to
check the vcs on whether this
Control: reassign -1 src:gcc-8
Control: tags -1 + patch
Hi Matthias,
I've updated the patch now. It has become fairly trivial.
We added support for "X-DH-Build-For-Type: target" a while ago. That
flag alone makes dh_strip choose the right tooling.
So whenever debhelper is recent enough, we can
Source: stockfish
Version: 9-1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
stockfish fails to build from source on armel, mips, mipsel, m68k,
powerpc, powerpcspe and sh4. A build log from mips ends with:
| g++ -o stockfish benchmark.o bitbase.o bitboard.o
Source: gcc-8
Version: 8-20180218-1
Severity: wishlist
We have long transitioned to PIE by default on all release architectures
now. Still each gcc-V package tracks the architectures that enable PIE
by default in an opt-in list (pie_archs).
Since it is the default, PIE is much better supported
Control: reopen -1
Control: reassign -1 src:gcc-8
Hi Matthias,
you requested that I send my unfinished work and here it goes. I've seen
that you have quickly applied my previous patches towards this matter
and would like to thank you. The attached patch was last tested on
8-20180402-1. I
Source: gcc-8
Version: 8-20180218-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block 666743 by -1
While working on coinstallable toolchains I ran into another problem.
When we want to install two native toolchains for different
architectures, we also want two native
Hi Jakub,
On Thu, Apr 19, 2018 at 12:31:03AM +0200, Jakub Wilk wrote:
> GCC no longer looks for "as" in the directory specified by the -B option:
Yes, I asked Matthias for passing --with-as to gcc.
> This breaks afl-gcc (part of the afl package), which uses the -B option to
> talk GCC into
Source: gcc-8
Version: 8-20180218-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block 666743 by -1
Hi Matthias,
this is my second patch towards gcc-for-host. It reworks the
debian/rules.conf variable arch_gnutype_map. The first major change is
that it is now being
Control: tags -1 + patch
On Wed, Mar 07, 2018 at 07:16:26PM +0100, Helmut Grohne wrote:
> Since it practically is the default "everywhere", can we move on to
> enable PIE for all "new" architectures by turning the opt-in list
> opt-out? While at it, can we keep t
+
+ * Non-maintainer upload.
+ *
+
+ -- Helmut Grohne Sat, 29 Sep 2018 13:31:54 +0200
+
gcc-8 (8.2.0-7) unstable; urgency=medium
* Update to SVN 20180917 (r264370) from the gcc-8-branch.
diff -u gcc-8-8.2.0/debian/control.m4 gcc-8-8.2.0/debian/control.m4
--- gcc-8-8.2.0/debian/control.m4
+
Source: gcc-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affetcs -1 + src:gcc-8-cross src:gcc-8-cross-ports
gfortran-8- presently Provides: gfortran-mod-15 and given
that gfortran-8- is Multi-Arch: foreign, this is provided
for any architecture. libopenmpi-dev Depends:
Hi Matthias,
On Tue, Dec 18, 2018 at 02:32:16AM +0100, Matthias Klose wrote:
> doesn't this approach of dropping the provides only defers the problem? You
> will
> see that again when cross building packages. So it looks to me that you want
> to
> include in the multiarch id into these
On Mon, Dec 03, 2018 at 01:30:43AM +0800, YunQiang Su wrote:
> YunQiang Su 于2018年12月2日周日 下午11:42写道：
> >
> > Matthias Klose 于2018年12月2日周日 下午4:51写道：
> > >
> > > On 02.12.18 09:31, Aron Xu wrote:
> > > > Running with Valgrind shows some errors:
> > >
> > > that might point to the
-09-18 17:21:59.0 +0200
@@ -1,3 +1,10 @@
+isl (0.20-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: Annotate Build-Depends: python3 with :any. (Closes: #-1)
+
+ -- Helmut Grohne Tue, 18 Sep 2018 17:21:59 +0200
+
isl (0.20-2) unstable; urgency=medium
On Thu, Jan 24, 2019 at 04:38:19PM +0100, Helmut Grohne wrote:
> Ultimately, this means that marking binutils- M-A:foreign was
> wrong. It means that binutils plays the same role as ruby, perl, python
> and even make: you can load shared objects into it, but much of the time
> yo
Source: gcc-8
Version: 8.3.0-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap
gcc-8 fails to cross build from source.
http://crossqa.subdivi.de/build/gcc-8_8.3.0-2_ppc64el_20190301030546.log
| powerpc64le-linux-gnu-g++-8 -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions
-fno-rtti
On Mon, Mar 11, 2019 at 04:34:35PM +, Santiago Vila wrote:
> Status: failed gcc-8-cross_26_amd64-20190309T042203.371Z
I've looked at the log and found a more useful bit:
| ../../gnatbind -I- -nostdinc
-I/<>/gcc/build/x86_64-linux-gnu/libgnatvsn
-I/<>/gcc/build/gcc/ada/rts -I.
1 - 100 of 164 matches
Mail list logo
