Peter Green writes:
> package:gcc-4.1
> version:4.1.2-7
> severity:serious
>
> from the relavent buildd logs:
Note, that the severity is not RC for 68k; I do not intend to fix
that. Same for arm, and arm porters don't seem to care that much, so
maybe we should drop arm as a release architecture?
Christian T. Steigies writes:
> Hi,
> I've been building gcc-4.2 on my mac for about a week now. The first try
> timed out, so I decided to continue the build manually. That failed last
> night, since my router had its daily crash and I did not run the build in a
> a screen session. When I continue
While having built and uploaded things correctly for experimental, I
didn't do the same for unstable, which now needs some manual
intervention building gnat-4.1 and gcj-4.1.
gnat-4.1 (mips mipsel s390 sparc):
- work in a sid chroot
- install gnat-4.1-base libgnat-4.1 libgnatprj4.1 libgnatvsn4.1
Michael Schmitz writes:
> > > While having built and uploaded things correctly for experimental, I
> > > didn't do the same for unstable, which now needs some manual
> > > intervention building gnat-4.1 and gcj-4.1.
> >
> > > gcj-4.1 (alpha arm m68k mips mipsel s390 sparc):
> > >
> > > - needs gcc
The plans for the GCC 4.2 transition were described in
http://lists.debian.org/debian-devel-announce/2007/06/msg8.html
Does any port still need to stick with GCC 4.1 for a while? Feedback
from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show
objections against the transition.
whats up with m68k?
- the last gcc-4.1 upload did fail to build
http://buildd.debian.org/fetch.cgi?&pkg=gcc-4.1&ver=4.1.2-14&arch=m68k&stamp=1185088210&file=log
- packages depending on `locales' cannot be built anymore.
Is there a buildd which holds back glibc-2.5 locales so that these
packag
Michael Schmitz writes:
> > - gcc-snapshot builds are missing for m68k.
>
> Bad build dependency on xulrunner, by brainfart of yours truly. I'll
> manually queue that one as well.
tell me what is wrong with
libxul-dev [!kfreebsd-amd64 !knetbsd-i386 !netbsd-i386 !hurd-i386]
please stop your fo
http://buildd.debian.org/fetch.cgi?&pkg=binutils&ver=2.17cvs20070804-1&arch=m68k&stamp=1186298213&file=log
Test results, compared with installed binutils:
W: [ld-elfvsb/elfvsb.exp] REGRESSION (PASS -> FAIL): visibility
(protected_weak) (non PIC, load offset)
W: [ld-elfvsb/elfvsb.exp] REGRESSION (
- binutils should be buildable with a recent kernel version
- patches in gcc-4.2 are updated, so please do build this package
- please build gcc-4.3 (experimental), and gcc-snapshot to get
test results of these versions. the builds require at least
256mb ram.
--
To UNSUBSCRIBE, email to
Stephen R Marenka writes:
> On Wed, Oct 03, 2007 at 08:28:56PM +0200, Matthias Klose wrote:
> > - binutils should be buildable with a recent kernel version
>
> done
>
> > - patches in gcc-4.2 are updated, so please do build this package
>
> failed
kernel
severity 446398 wishlist
tag 446398 + moreinfo
thanks
> gcc-4.1 causes other packages to FTBFS on m68k. This has happened for
> several versions and with several versions of binutils.
it looks these problems are related to -pie?
> Please let me know how I can help.
please address the problem w
currently gcc-4.3 fails to build on m68k:
libtool: compile: /build/buildd/gcc-4.3-4.3-20080112/build/./gcc/xgcc
-B/build/buildd/gcc-4.3-4.3-20080112/build/./gcc/ -B/usr/m68k-linux-gnu/bin/
-B/usr/m68k-linux-gnu/lib/ -isystem /usr/m68k-linux-gnu/include -isystem
/usr/m68k-linux-gnu/sys-include
Besides m68k hopelessly being behind we do have serious problems on
alpha, arm and hppa.
- on arm, the bytecode compiler (ecj) doesn't produce correct code.
there is currently a workaround to build the package on arm using
byte-compiled code built on another architecture. Aurelian has
m
Is there any progress in getting gcc-4.3/gcj-4.3 built? Is the kernel
header problem solved (or is there a workaround)? Would it help
to disable running the testsuite for an initial upload?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contac
gcj-4.3 failed to build on m68k trying to build interpret.cc, timing
out after 600 minutes. this is one of the problematic files taking a
huge time to build. please could somebody validate if there is still
progress, or if it's an infinite loop? Please try on a machine with at
least 256MB RAM.
--
please could somebody of you give some estimatates when the gcc-4.3
build will hit the archive (if it is still building)?
thanks, Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the openjdk-6 6b11-4 should build on m68k. It may take a few weeks,
but I currently don't see any issue with it. If you do so, please keep
the build tree, so that the testsuite can be run, after the build
finishes (taking some more weeks to finish).
thanks, Matthias
--
To UNSUBSCRIBE, email to
See
http://buildd.debian.org/fetch.cgi?&pkg=openjdk-6&ver=6b11-7&arch=m68k&stamp=1221384832&file=log
not sure about this problem. the segfault is seen while unpacking an
archive with jar (pointing to fastjar). I'd appreciate if somebody
could investigate and maybe make a NMU for fastjar if a fix
Hi,
would it be possible to start builds of these two?
thanks, Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi,
openjdk-6 in unstable is updated to the 6b14 code drop, built from a recent
IcedTea snapshot. There are a few regressions in the ports which don't use the
hotspot VM, but the Zero VM. Help from porters would be appreciated.
There are two new binary packages offering additional JVMs:
- openj
Besides the open license issue, are there any objections from port maintainers
to make GCC-4.4 the default?
As a first step that would be a change of the default for C, C++, ObjC, ObjC++
and Fortran.
I'm not sure about Java, which show some regressions compared to 4.3. Otoh it's
not amymore
For wheezy I'm planning to change the linking behaviour for DSOs (turning on
--as-needed and --no-copy-dt-needed-entries. The rationale is summarized in
http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues
with these changes on some of the Debian ports, and if we need t
On 15.11.2010 07:16, Roland McGrath wrote:
airlied_, does Fedora use --as-needed by default? Fedora 14 too?
mattst88: yes
The naming of the options makes people easily confused.
--no-add-needed is the only option Fedora's gcc passes.
yes, OpenSuse is using --as-needed, but not --no-add-ne
On 14.11.2010 16:06, Roger Leigh wrote:
While I understand the rationale for --no-copy-dt-needed-entries for
preventing encapsulation violations via indirect linking, I don't agree
with the use of --as-needed *at all*. If a library has been explicitly
linked in, it shouldn't be removed. This is
On 14.11.2010 13:19, Julien Cristau wrote:
On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
For wheezy I'm planning to change the linking behaviour for DSOs
(turning on --as-needed and --no-copy-dt-needed-entries. The
rationale is summarized in
http://wiki.debian.org/Tool
On 16.11.2010 01:24, Roger Leigh wrote:
On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote:
On 14.11.2010 16:06, Roger Leigh wrote:
While I understand the rationale for --no-copy-dt-needed-entries for
preventing encapsulation violations via indirect linking, I don't agree
wit
On 16.11.2010 10:42, Roger Leigh wrote:
On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote:
On 14.11.2010 13:19, Julien Cristau wrote:
On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
For wheezy I'm planning to change the linking behaviour for DSOs
(turning on
I'll make gcc-4.5 the default for (at least some) architectures within the next
two weeks before more transitions start. GCC-4.5 is already used as the default
compiler for almost any other distribution, so there shouldn't be many surprises
on at least the common architectures. About 50% of the b
On 02.03.2011 07:36, Konstantinos Margaritis wrote:
> On 2 March 2011 03:34, Matthias Klose wrote:
>
>> I'll make gcc-4.5 the default for (at least some) architectures within the
>> next
>> two weeks before more transitions start. GCC-4.5 is already used as the
>
On 02.03.2011 17:54, Martin Guy wrote:
> On 2 March 2011 02:34, Matthias Klose wrote:
>> armel (although optimized for a different processor)
>
> Hi
> For which processor (/architecture) is it optimized, and do you mean
> optimized-for, or only-runs-on?
> I ask
On 04/17/2011 09:33 PM, Adam D. Barratt wrote:
On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote:
I'll make gcc-4.5 the default for (at least some) architectures within the next
two weeks before more transitions start. GCC-4.5 is already used as the default
compiler for almost any
On 04/26/2011 05:31 PM, Konstantinos Margaritis wrote:
On 26 April 2011 18:03, Matthias Klose wrote:
I'll make GCC 4.6 the default after the release of
GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
powerpc.
Could you include armhf in the list as well?
yes, f
On 04/26/2011 09:28 PM, Kurt Roeckx wrote:
On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote:
On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote:
I'll make GCC 4.6 the
default after the release of GCC 4.5.3, expected later this week, at
least on amd64, armel, i38
Please have a look at the gcc-4.7 package in experimental, update patches (hurd,
kfreebsd, ARM is fixed in svn), and investigate the build failures (currently
ia64, but more will appear).
Matthias
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe".
GCC-4.7 packages are now available in testing and unstable; thanks to Lucas'
test rebuild, bug reports are now filed for these ~330 packages which fail to
build with the new version [1]. Hints how to address the vast majority of these
issues can be found at [2].
I'm planning to work on these
GCC 4.7 is now the default for x86 architectures for all frontends except the D
frontends, including KFreeBSD and the Hurd.
There are still some build failures which need to be addressed. Out of the ~350
bugs filed, more than the half are fixed, another quarter has patches available,
and the remai
On 07.05.2012 19:35, Thorsten Glaser wrote:
> 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?
I don&#x
It's time to change the Java default to java7, and to drop java support on
architectures with non-working java7.
Patches for the transition to Java7 should be available in the BTS, mostly
submitted by James Page. Some may be still lurking around as diffs in Ubuntu
packages, apologies for that. T
Am 07.05.2013 15:25, schrieb Matthias Klose:
> The decision when to make GCC 4.8 the default for other architectures is
> left to the Debian port maintainers.
[...]
> Information on porting to GCC 4.8 from previous versions of GCC can be
> found in the porting guide http://gcc.gnu
Am 13.06.2013 21:47, schrieb Thorsten Glaser:
> Matthias Klose dixit:
>
>> The Java and D frontends now default to 4.8 on all architectures, the Go
>> frontend stays at 4.7 until 4.8 get the complete Go 1.1 support.
>
> I’d like to have gcj at 4.6 in gcc-defaults for m68k
Am 13.06.2013 16:46, schrieb Steven Chamberlain:
> Hi,
>
> On 13/06/13 13:51, Matthias Klose wrote:
>> GCC 4.8 is now the default on all x86 architectures, and on all ARM
>> architectures (the latter confirmed by the Debian ARM porters). I did not
>> get
>
Am 14.06.2013 23:03, schrieb Nicolas Boulenguez:
> Package: gnat-4.6
> Version: 4.6.4-1
> Severity: minor
>
> Hello.
> libncursesada FTBFS on m68k with a GNAT BUG DETECTED box, see
> http://buildd.debian-ports.org/status/fetch.php?pkg=libncursesada&arch=m68k&ver=5.9.20110404-7&stamp=1367171074
> T
Am 15.06.2013 03:22, schrieb Stephan Schreiber:
> GCC-4.8 should become the default on ia64 soon; some other changes are
> desirable:
> - The transition of gcc-4.8/libgcc1 to libunwind8.
> - A removal of the libunwind7 dependency of around 4600 packages on ia64 -
> when
> they are updated next ti
Yann Dirson writes:
> I have several packages (e2fsprogs, bigloo) that fail to build on
> m68k, apparently due to one or more gcc bug(s). Maybe that's the same
> as #146006, and #89023, but I can't tell that myself.
>
> Madkiss suggested forcing the use of gcc-3.2. But if this compiler is
> offi
Good news first. It becomes more tedious to track the bug-free
packages. Besides the usual serious bugs, the following issues remain:
- wxwindows2.2 is still unbuildable in unstable, not yet removed
from unstable, package maintainer does not respond. Oh fun!
- postgresql: doesn't go to testing
Richard Zidlicky writes:
> On Tue, Oct 29, 2002 at 06:10:57PM +0100, Yann Dirson wrote:
> > On Mon, Oct 21, 2002 at 09:43:05PM +0200, Matthias Klose wrote:
> > > Yann Dirson writes:
> > > > I have several packages (e2fsprogs, bigloo) that fail to build on
> >
GOTO Masanori writes:
> > On Sun, Jan 19, 2003 at 07:48:04PM -0800, Jeff Bailey wrote:
> > > I haven't seen mention of it on this list, so I wanted to bring it up -
> > > Bug #175526 against glibc is m68k specific.
> >
> > interesting. I am running glibc-2.3 and gcc-3.2 without much problems
>
> glibc 2.3.1-14 should be entering testing "tomorrow" (sometime around 30
> hours from now, depending on your mirror). Along with it, some 800 other
> source packages and all their binaries are expected to be updated. For
> those of you running testing systems, please take care of the next few
> d
submitted http://gcc.gnu.org/PR12371, that gcc-3.4/gcc-snapshot
doesn't bootstrap anymore. Please could somebody try to mail the
failure down to a specific week or day? bootstrapping with c would
suffice. either do it manually or use contrib/reghunt.
Any volunteer?
--- Begin Message ---
PLEASE R
there is a workaround (gcc-3.2), therefore the severity could be
reduced, otoh it's generating wrong code. please could you check, if
this one is reproducible in gcc-3.4?
The last awk sucessfully built on m68k is the 3.3 branch 20040728.
Matthias
Fumitoshi UKAI writes:
> clone 278135 -
Kevin B. McCarty writes:
> Hi all,
> I am just wondering if bug # 225621 (g77-3.3: sometimes generates invalid
> assembly code on m68k) has been noticed, since I haven't seen it mentioned
> anywhere on these mailing lists. Apologies if I'm being redundant.
it needs to be rechecked using gcc-snaps
Package: aranym
There are rumors, that aranym is able to run Debian m68k-linux. Please
add some documentation/howto.
This may be a compiler bug. On ia64 the package builds using gcc-3.4
from experimental. I didn't try to build 5.8.3 to see if this was
triggered by the new perl version.
Maybe it's an alternative to build miniperl with gcc-2.96 on ia64 and
gcc-2.95 on arm and m68k?
Christian T. Steigies writes:
> On Fri, Jun 10, 2005 at 01:58:30PM +0200, Matthias Klose wrote:
> > Christian T. Steigies writes:
> > > Package: gij-4.0
> > > Version: 4.0.0-9
> > > Severity: important
> > >
> > > My m68k buildd fa
M68k porters,
as almost all new releases, GCC 4.0 not only fixes bugs, but
introduces some regressions compared to the older releases. Currently
GCC maintainance for m68k in Debian is not active. Although I do have
access to m68k platforms, I currently do not have the resources to
handle and for
Stephen Gran writes:
> Package: gcc-4.0
> Version: 4.0.1-2
> Followup-For: Bug #317475
>
> Also see
> http://buildd.debian.org/fetch.php?&pkg=gmp&ver=4.1.4-8&arch=m68k&stamp=1121077632&file=log&as=raw
Please extract the preprocessed source, and forward the bug report
upstream. See http://lists.de
Steve M. Robbins writes:
> On Wed, Jul 20, 2005 at 03:40:23PM +0200, Matthias Klose wrote:
> > Package: gmp
> > Version: 4.1.4-8
> > Severity: serious
> >
> > As a workaround, please build gmp using gcc-3.4/g++-3.4 on m68k and/or
> > lower the optimizatio
reassign 327780 m68k
thanks
that's unreproducible on crest/sid, although I can reproduce it on
another machine with the very same versions of gcc-4.0 and libc6. So
why not file it for libc6?
The point of reassigning the report to an unknown package is to ask,
if it's time to drop m68k from the re
Marco d'Itri writes:
> On Sep 23, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
>
> > > >Well, the real problem here is gcc-4.0 especially at -O3. On m68k it ICE
> > > >instead of spewing wrong code like on i386. We are very good at spotting
> > > >ICE but poor at spotting wrong code generation which
please requeue gjdoc on m68k without any timeouts.
thanks, Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Stephen R Marenka writes:
> Does anyone see any other toolchain issues (or other issues) besides
> TLS in libc?
the m68k related patches in gcc-4.2 need to be updated, test results
for gcc-snapshot be submitted.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Tro
- binutils currently FTBFS, this failure appeared after glibc-2.5 was
built on m68k?
see
http://buildd.debian.org/fetch.cgi?&pkg=binutils&ver=2.17cvs20070426-4&arch=m68k&stamp=1178147857&file=log
- gcc-4.2 needs all the m68k patches be reenabled, which were applied
to gcc-4.1. If the packag
Wouter Verhelst writes:
> On Fri, May 04, 2007 at 05:24:35AM +0200, Matthias Klose wrote:
> > - gcc-4.2 needs all the m68k patches be reenabled, which were applied
> > to gcc-4.1. If the package builds, it may break m68k as gcc-4.1 did
> > during the etch release cycle
Am 29.10.2013 17:48, schrieb Ian Jackson:
> (Mind you, I have my doubts about a process which counts people
> promising to do work - it sets up some rather unfortunate incentives.
> I guess it's easier to judge and more prospective than a process which
> attempts to gauge whether the work has been
Am 17.11.2013 01:05, schrieb Thorsten Glaser:
> + * rules.conf: Do not force libcloog-isl-dev (>= 0.18) on older
> +distribution releases that do not have this version yet.
>
> ISTR writing about this already: as I regularily build cross
> compilers for wheezy/amd64 which doesn’t have this ve
gcc-4.9 is uploaded to experimental, asking the porters to watch for build
failures and corresponding patches. See
https://buildd.debian.org/status/package.php?p=gcc-4.9&suite=experimental
These are already fixed in the vcs.
- fixed the gospec.c ftbfs on archs without ld.gold
- fixed the g++ b
Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar:
> For mips/mipsel, I - fix toolchain issues together with other developers at
> ImgTec
It is nice to see such a commitment, however in the past I didn't see any such
contributions.
Matthias
--
To UNSUBSCRIBE, email to debian-68k-requ...@l
With gcc-4.9 now available in testing, it is time to prepare for the change of
the default to 4.9, for a subset of architectures or for all (release)
architectures. The defaults for the gdc, gccgo, gcj and gnat frontends already
point to 4.9 and are used on all architectures. Issue #746805 tracks
t;> "just know" what to do, but I haven't the slightest idea of where to begin.
>> I have a box with gcc-4.9, plenty of disk space, and electricity to burn.
>> Where do I start?
>>
>> Patrick
>>
>>
>>> On Thu, May 8, 2014 at 10:25 AM, M
Am 11.06.2014 10:12, schrieb Thorsten Glaser:
> buildd on ara5 for m68k dixit:
>
>> Changes:
>> gcc-defaults (1.128) unstable; urgency=medium
>> .
>> * Default to GCC 4.9 for all architectures except m68k, or1k, powerpcspe,
>> sh4 and x32.
>
> Hi porters, is there any reason for m68k to not
Hi,
I'll change the default GCC to 4.9 with a gcc-defaults upload next week for the
remaining architectures, then updating the build-essential package to require
GCC 4.9.
Matthias
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Conta
Am 15.07.2014 20:37, schrieb Thorsten Glaser:
> Hi Matthias,
>
> can we please have that patch integrated in a binutils
> upload some time?
sure, will be there with the next update, however I'd like to get the current
version and gcc 4.9.1 into testing first.
--
To UNSUBSCRIBE, email to debian
On 09/03/2015 08:53 AM, Emmanuel Bourg wrote:
> Le 03/09/2015 00:39, Matthias Klose a écrit :
>
>> I disagree. Please revert mips/mipsel back to gcj, or fix the mips/mipsel
>> builds
>> for openjdk-8 (and for openjdk-9). The other alternative would be not to
>>
On 19.12.2015 14:57, John Paul Adrian Glaubitz wrote:
Hello!
gcc-5 is currently BD-Uninstallable because I am building gcc-5 with
gnat-5 enabled right now. For that purpose, Matthias has provided
me with cross-compiled gnat-5 packages for m68k (and also sh4 and
sparc64) which work fine.
I will
Package: gnat-6
Version: 6-20160205-1
trying to build a cross compiler:
checking size of int... Run-time library configured incorrectly
(requesting support for Frontend ZCX exceptions)
compilation abandoned
Run-time library configured incorrectly
(requesting support for Frontend ZCX exceptions)
While the Debian Release team has some citation about the quality of the
toolchain on their status page, it is not one of the release criteria documented
by the release team. I'd like to document the status how I do understand it for
some of the toolchains available in Debian.
I appreciate that t
On 10.09.2016 09:59, Paul Gevers wrote:
> Hi,
>
> On 10-09-16 00:48, Matthias Klose wrote:
>> - fpc not available on powerpc anymore (may have changed recently)
>
> For whatever it is worth, this was finally fixed this week. It is
> missing on mips*, ppc64el and s390
On 15.09.2016 22:43, Helge Deller wrote:
> Hi Matthias,
>
> On 10.09.2016 00:48, Matthias Klose wrote:
>> While the Debian Release team has some citation about the quality of the
>> toolchain on their status page, it is not one of the release criteria
>> documented
&
On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
>
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.
No, you are not maintaini
[CCing porters, please also leave feedback in #835148 for non-release
architectures]
On 29.09.2016 21:39, Niels Thykier wrote:
> Hi,
>
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
> * It is a substantial har
On 03.12.2016 22:04, John Paul Adrian Glaubitz wrote:
> On 12/03/2016 10:02 PM, Andreas Schwab wrote:
>>> patching file src/gcc/ada/s-memory.adb
>>> Hunk #1 FAILED at 47.
>>> Hunk #2 succeeded at 113 (offset 13 lines).
>>> 1 out of 2 hunks FAILED -- rejects in file src/gcc/ada/s-memory.adb
>>> patc
Package: src:gcc-7-cross-ports
Version: 1
Trying to build a gnat m68k cross compiler fails with:
/home/packages/cross/7/p/gcc-7-cross-ports-1/gcc/build/./gcc/xgcc
-B/home/packages/cross/7/p/gcc-7-cross-ports-1/
gcc/build/./gcc/ -B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem
/usr/m
On 06.08.2017 11:04, John Paul Adrian Glaubitz wrote:
> On 08/06/2017 05:00 PM, John Paul Adrian Glaubitz wrote:
>> I am currently testing the updated patch on armel, armhf and
>> m68k. If it succeeds, it should be included for the next upload
>> and the workaround for m68k from #868255 [1].
>
> .
According to [1], binutils 2.31 (currently in experimental) will branch in about
a week, and I'll plan to upload the branch version to unstable. Test results
are reported to [2], these look reasonable, except for the various mips targets,
however as seen in the past, it doesn't make a differenc
GCC 8 is available in testing/unstable, and upstream is approaching the first
point release. I am planning to make GCC 8 the default at the end of the week
(gdc and gccgo already point to GCC 8). Most runtime libraries built from GCC
are already used in the version built from GCC 8, so I don't ex
On 07.07.18 17:24, YunQiang Su wrote:
> Niels Thykier 于2018年6月28日周四 上午4:06写道：
>> List of concerns for architectures
>> ==
>>
>> The following is a summary from the current architecture qualification
>> table.
>>
>> * Concern for ppc64el and s390x: we are dependent
On 13.04.19 17:01, Joerg Jaspert wrote:
> On 15371 March 1977, Aurelien Jarno wrote:
>
>>> How is the move to debian-ports supposed to happen? I won't have the
>>> time to do anything about it within the 2 weeks.
>
>> The process to inject all packages to debian-ports is to get all the
>> deb, ud
The recent gcc-8 and gcc-9 uploads to unstable are now built using pgo and lto
optimization. Not on all architectures, see debian/rules.defs. On the plus
side the compilers are 7-10% faster, however the build time of the compiler is
much longer, adding 10-20 hours. If people feel that this isn't
GCC 9 was released earlier this year, it is now available in Debian
testing/unstable. I am planning to do the defaults change in mid August, around
the time of the expected first GCC 9 point release (9.2.0).
There are only soname changes for rather unused shared libraries (libgo)
involved, and the
On 24.10.19 13:16, Anthony Green wrote:
libffi 3.3 release candidate 1 is available for testing...
https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz
https://github.com/libffi/libffi/releases/tag/v3.3-rc1
test results from
https://buildd.debian.org/status/package
Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream
branch, and binutils based on a binutils package taken from the 2.35 branch.
I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available
(upstream targets mid July). binutils will be updated before mak
On 12/1/20 5:02 AM, YunQiang Su wrote:
> I am sorry for the later response.
>Hi,
>
> I am an active porter for the following architectures and I intend
> to continue this for the lifetime of the Bullseye release (est. end
> of 2024):
>
> For mipsel and mips64el, I
> - test most pac
Link time optimizations are an optimization that helps with a single digit
percent number optimizing both for smaller size, and better speed. These
optimizations are available for some time now in GCC. Link time optimizations
are also at least turned on in other distros like Fedora, OpenSuse (
93 matches
Mail list logo
