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
[keeping all the people in the CC]
Scanning the reports, I see Matthew Wilcox beeing asked about:
In either case, I will need a knowledgeable hppa person to advise,
discuss and help generate patches for this to get fixed any time soon.
Gcl can build its own bfd library, so patches here can
Camm Maguire writes:
Greetings!
Matthias Klose [EMAIL PROTECTED] writes:
[keeping all the people in the CC]
Scanning the reports, I see Matthew Wilcox beeing asked about:
In either case, I will need a knowledgeable hppa person to advise,
discuss and help generate patches
AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
code due to the changed exception handling (now DWARF2 based). As
libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
Currently 3.2 is in unstable only. Would you want to start the
recompilation before 3.2 based
Matthias Klose writes:
AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
code due to the changed exception handling (now DWARF2 based). As
libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
Currently 3.2 is in unstable only. Would you want to start
Randolph Chung writes:
In reference to a message from Matthias Klose, dated Mar 01:
Matthias Klose writes:
AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
code due to the changed exception handling (now DWARF2 based). As
libstdc++ in 3.2 and 3.2 have the same soname
binutils-2.13.90.0.18 works ok.
See
http://buildd.debian.org/fetch.php?pkg=gcc-3.3ver=1%3A3.3ds9-2arch=hppastamp=1053264270file=logas=raw:
./xgcc -B./ -B/usr/hppa-linux/bin/ -isystem /usr/hppa-linux/include -isystem
/usr/hppa-linux/sys-include -O2 -DIN_GCC-W -Wall -Wwrite-strings
Package: setserial
Version: 2.17-33
Severity: grave
This is an A500. The boot breaks during the run of seterial. disabling
setserial lets the machine boot again.
Cleaning: /etc/network/ifstate.
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces... done.
Starting portmap
gcc-3.3 is configured with --enable-sjlj-exceptions (done to keep
compatibility with gcc-3.2). I don't know if the dwarf2 unwinder will
work with this setup.
David Mosberger writes:
Package: gcc-3.3
Version: 1:3.3.3-0pre0
Severity: important
Tags: sid
It appears that the behavior of Debian
Package: binutils
Version: 2.14.90.0.7
Tags: patch
Please apply the following patch to build an binutils-hppa64 package,
which is needed together with gcc-3.3-hppa64 to build the 64bit
kernels for hppa-linux. The tools currently used to build the 64bit
aren't packaged at all, so this is a first
I think I did see this first with gcc-3.3 from 20031229. Running the
3.3 testsuite (gcc) doesn't terminate. Instead, I see expect eating
all CPU time, together with syslogd and klogd. /var get's filled with
log messages in kern.log, syslog and debug.
The machine is a A500, kernel from the
tags 228421 + woody
tags 228421 + fixed-upstream
thanks
Well, maybe a recompilation and binary NMU for apache would suffice?
Should the report be reassignd to apache?
Willy Tarreau writes:
Package: gcc
Version: 2:3.0.4-5
Kernel: Linux hp 2.4.24-pa0 #1 Sun Jan 11 18:48:21 CET 2004 parisc
Grant Grundler writes:
On Sun, May 09, 2004 at 06:01:52PM +0100, Martin Michlmayr wrote:
* Adrian Bunk [EMAIL PROTECTED] [2004-04-02 02:11]:
What are your plans with gcc-3.0? It seems there are only a few
build-depends on hppa.
Let's check, it's used on hppa for:
- kernel
Martin Michlmayr writes:
* Adrian Bunk [EMAIL PROTECTED] [2004-04-02 02:11]:
What are your plans with gcc-3.0? It seems there are only a few
build-depends on hppa.
The idea was to keep gcc-3.0 for the libstdc++3 package to satisfy
external/third party software. But currently no such
Matthew Wilcox writes:
On Mon, Jun 28, 2004 at 07:08:36PM +0200, Matthias Klose wrote:
hppa is the only platform with gcc-3.0/g++-3.0. Is this version still
needed for hppa builds, or can it be removed? On all other platforms,
we just build the libstdc++ runtime library (but doesn't seem
Carlos O'Donell writes:
Anyone else using debootstrap recently to get a sid chroot?
[EMAIL PROTECTED]:~/src$ mkdir sid_chroot
[EMAIL PROTECTED]:~/src$ sudo debootstrap sid sid_chroot/
I: Retrieving debootstrap.invalid_dists_sid_Release
I: Validating debootstrap.invalid_dists_sid_Release
Joel Soete writes:
On Wed, Jun 22, 2005 at 04:07:35PM +, Joel Soete wrote:
if I link hppa64-linux-ld - hppa64-linux-gnu-ld
(and remove the objets):
[...]
hppa64-linux-ld -r -o init/mounts.o init/do_mounts.o
init/do_mounts_md.o
init/do_mounts.o: file not
--j79F1xXV029481.1123599719/bolero.cs.tu-berlin.de--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tsd78163 writes:
I now grab the debian libc6 pkg src to rebuild it with my own new gcc-4.0
(but my chroot disk stand on a b180 so will take time too :-)
you can grab the packages from incoming as well, will be available in
unstable tonight.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Following the discussion on parisc, I uploaded glibc built with
gcc-3.4. Validated, that gcc-4.0 bootstraps again and the python build
errors are gone.
Please make this change for the next sourceful upload.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
John David Anglin writes:
Following the discussion on parisc, I uploaded glibc built with
gcc-3.4. Validated, that gcc-4.0 bootstraps again and the python build
errors are gone.
Does this fix GCC PR 23731?
can't check, it currently segfaults trying to generate the
classmap.db (same thing
John David Anglin writes:
Following the discussion on parisc, I uploaded glibc built with
gcc-3.4. Validated, that gcc-4.0 bootstraps again and the python build
errors are gone.
Does this fix GCC PR 23731?
down to 475 test failures. Maybe related to PR23602
--
To UNSUBSCRIBE, email to
Which gcc-X.Y-hppa64 variants are still needed for Debian sid/etch?
Currently compilers are built for 3.3, 3.4, 4.0 and 4.1, the latter
one for experimental. Is it time to drop some of these?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
John David Anglin writes:
please see http://bugs.debian.org/353346
Should be fixed. See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html
with this change (and the typo fix), gcj-dbtool segfaults:
(gdb) run -n classmap.db
Starting program: /usr/bin/gcj-dbtool-4.1 -n classmap.db
[should we drop parisc-linux?]
John David Anglin writes:
Er, no; we're talking about official Debian packages here, and the
libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that
GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting
in the
Falk Hueffner writes:
Steve Langasek [EMAIL PROTECTED] writes:
Hi Matthias,
works for me.
Have you tried building it with prctl --unaligned=signal? This is not
the default on hppa, but it's used on the autobuilders because it
catches potentially costly programming errors.
is
reassign 342545 qt-x11-free
thanks
please make sure, that qt-x11-free is built using g++-4.1 on hppa. The
binary packages still depend on libgcc2 in some way.
Note, that (before the release) we need to rebuild all binaries
depending on libgcc2 on hppa, so that the dependency is replaced by
The qt-x11-free package builds fine with a standard Debian setup.
Building with prctl --unaligned=signal makes the bug reproducible.
Christopher Martin writes:
reassign 342545 libgcc2
stop
On Thursday 10 August 2006 00:25, Steve Langasek wrote:
It hasn't been, because I can't see any way
Will gcc-4.0 be dropped as a build dependency for etch, or be kept?
And on which architectures?
Would you mind dropping gcc-4.0 from etch for some architectures?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Can gcc-4.0-hppa64 and gcc-4.0 be dropped for etch? My current plan is
to keep gcc-4.1-hppa64 and gcc-3.4-hppa64. we can drop gcc-3.4-hppa64
as well, but will have to keep the other compilers from the GCC-3.4
package anyway.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Packages still depending on libgcc2, without depending on libg2c0
(can't do anything about libg2c0, built from gcc-3.4).
ale
aqsis
aqsis-libs
basilisk2
boson-base
cbedic
kfolding
ksocrat
libmyspell3c2
libosgcal0
libsimpledb2
netgen
parrot
spectemu-common
stella
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
The proposed fix seems to be wrong, as it disables the backport on all
architectures. Please could you recheck with current trunk? As jda
suggested, another backport is missing for hppa.
Matthias
Sébastien Bernard writes:
Ok, I nailed it.
I removed PR20218 patch and generated a 4.1.2-12+b1
Testing 20070630 including the fix for PR rtl-optimization/32296 shows
many new C++ and libstdc++ regressions.
A Debian package for unstable will be available tonight in the archives.
Matthias
Results for 4.3.0 20070630 (experimental) testsuite on hppa-unknown-linux-gnu
LAST_UPDATED:
Target:
John David Anglin writes:
Testing 20070630 including the fix for PR rtl-optimization/32296 shows
many new C++ and libstdc++ regressions.
We also have problems with building hppa64 and Ada. So, things are
a mess at the moment...
The hppa64 cross compiler at least did build; Ada is broken
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.
With recent 64bit kernels linux32 seems to work,
$ linux32 uname -m
parisc
but
$ linux32 /usr/share/misc/config.guess
hppa2.0-unknown-linux-gnu
which seems to break some configury only knowing about hppa and
hppa64. Is config.guess correct, and should configure scripts be
changed?
Matthias
John David Anglin writes:
believe this can be fixed. For example, libgmp treats hppa2.0w as
indicating a 64-bit runtime. I'm sure you have hit this.
no python's internal copy of libffi :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
For all ports besides alpha and hppa we plan to make GCC-4.3 the
default compilers for lenny.
- both alpha and hppa show regressions in the glibc testsuite when
built with GCC-4.3
- gcj has a lot of regressions in 4.3 on alpha (but doesn't work in
4.2 either).
- gij/gcj shows bus
Carlos O'Donell writes:
- gij/gcj shows bus errors on hppa (either 4.2 or 4.3).
Has gij/gcj ever worked on hppa-linux?
at least the gij/gcj before adding support for generics (1.5) did
work. Now that a working runtime is required for the compiler makes
things different. Please try to run
Carlos O'Donell writes:
On Sat, Mar 22, 2008 at 5:10 PM, Matthias Klose [EMAIL PROTECTED] wrote:
Carlos O'Donell writes:
- gij/gcj shows bus errors on hppa (either 4.2 or 4.3).
Has gij/gcj ever worked on hppa-linux?
at least the gij/gcj before adding support for generics
Sergei, expect using tcl8.4 does not work well on hppa, therefore the
GCC testsuite uses expect-tcl8.3.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378394 ,
maybe run the GCC testsuite using expect instead of expect-tcl8.3.
Matthias
Sergei Golovan writes:
Source: gcc-4.2
Severity:
Proposing to drop gcc-3.4 for the lenny release, at least on the hppa
architecture. There are currently some packages left build-depending
on gcc-3.4/g++-3.4 [1]. Could the hppa port maintainers agree on
dropping support for these packages for lenny? That would have the
additional advantage
Ludovic Brenta writes:
Now that gnat-4.3 is on all architectures, I would like to upload
gcc-defaults 1.70 making it the default on alpha, mips and mipsel as
for all other archs.
As is, gcc-defaults cannot enter testing because on alpha, mips and
mipsel, if depends on gnat-4.2 which is not
Grant Grundler writes:
On Sun, Apr 13, 2008 at 11:53:54PM +0200, Aurelien Jarno wrote:
...
FYI the glibc testsuite with gcc-4.3 on HPPA now gives the same results
than with gcc-4.2, except on one FPU test, due to a bug in the *glibc*.
So it *seems* HPPA is ready for gcc-4.3 by default.
clone 482902 -1
reassign -1 general
severity -1 serious
thanks
Aurelien Jarno writes:
severity 482902 wishlist
tag 482902 + upstream
tag 482902 + wontfix
thanks
Matthias Klose a écrit :
Package: glibc
Version: 2.7-11
Severity: important
Please build libc6-hppa64 and libc6-hppa64
Package: icon
Version: 9.4.3-2
Severity: serious
according to
http://buildd.debian.org/fetch.cgi?pkg=iconver=9.4.3-2arch=hppastamp=1226637845file=log
icon ftbfs on hppa, but nevertheless can be found in the
archive. rebuilding the package locally shows the very same build
failure.
How was the
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:
-
dann frazier schrieb:
On Tue, Apr 28, 2009 at 05:09:25PM -0400, Carlos O'Donell wrote:
On Tue, Apr 28, 2009 at 4:12 PM, Luk Claes l...@debian.org wrote:
* Has progress been made regarding proper java support?
What is considered proper java support? GCJ?
Dave, have you tinkered with GCJ
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
+linux-parisc (hppa kernel, compiler and !debian tech forum)
Neil,
thanks for the summary. I know this is an unpleasant business in general.
On Tue, Jun 02, 2009 at 03:07:35PM +0100,
Luk Claes schrieb:
Matthias Klose wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
http://lists.debian.org/debian-release/2009/04/msg00303.html
Note
Luk Claes schrieb:
Matthias Klose wrote:
According to the buildd logs the openjdk-6 6b14-4 build for mipsel did
finish on
Jun 20, but was not uploaded until now. Is there any interest within the
mips
porters on openjdk-6 on mips*, or should we just remove it from the archive
and
drop
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
On 06.09.2009 10:56, Sergei Golovan wrote:
On Sun, Sep 6, 2009 at 4:09 AM, Dominique
Belhachemidomi...@cs.tu-berlin.de wrote:
Hi,
The default Tcl/Tk version in Lenny is 8.4.
What Tcl/Tk version will be chosen for Squeeze?
Currently, there are three Tcl/Tk versions in sid and squeeze: 8.3,
On 08.11.2009 20:47, Carlos O'Donell wrote:
On Sun, Nov 8, 2009 at 1:42 PM, Carlos O'Donellcar...@systemhalted.org wrote:
Always the same crash for all the failures I've looked at. Hopefully
this is something trivial that was missed.
The current libc is missing my patches to fix
On 16.11.2009 07:24, Carlos O'Donell wrote:
On Sun, Nov 15, 2009 at 11:03 PM, Felipe Satelerfsate...@gmail.com wrote:
I think the analysis it is wrong, because after the scons clean stage, the
cache is deleted. Relevant section from debian/cdbs/1/class/scons.mk:
scons-clean::
On 20.11.2009 16:44, Carlos O'Donell wrote:
On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarnoaurel...@aurel32.net wrote:
Domenico Andreoli a écrit :
On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klosed...@debian.org wrote:
On
On 07.12.2009 14:36, Onkar Shinde wrote:
Hi,
java3d currently fails to build on hppa because it uses some sun
specific APIs and default-jdk is GCJ on hppa. A solution for this
could be to use openjdk-6-jdk build-dep instead of default-jdk. But
the problem is that there are no openjdk-* packages
On 05.01.2010 19:13, Tom Rodriguez wrote:
openjdk builds on hppa, but doesn't run (yet). Andrew Haley once debugged it
and found out at least one things which would need to be fixed: the assumption
in the C++ interpreter that the stack always grows downwards, and not upwards
as on hppa.
clone 561414 -1
reassign 561414 libmatthew-java
tag -1 + help
severity -1 important
thanks
please build the java docs only, if bulding the binary-indep packages in
libmatthew-java.
debian-hppa, I'd like ask for some help with this, or with the openjdk-6 port
for hppa. is anybody working on
severity 579424 important
tag 579424 + moreinfo
thanks
the bug report mentions a workaround, lowering severity. Information about
gcc-4.5/gcc-snapshot is missing.
--
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
severity 579424 important
thanks
On 29.06.2010 02:29, Sune Vuorela wrote:
severity 579424 serious
thanks
On Tuesday 29 June 2010 01:48:15 Matthias Klose wrote:
severity 579424 important
tag 579424 + moreinfo
thanks
the bug report mentions a workaround, lowering severity.
Hi
I don't see
On 08.07.2010 01:42, brian m. carlson wrote:
Package: gcc-4.4
Version: 4.4.4-6
Severity: wishlist
Because the ELF ABI for hppa requires relative jumps which are limited
to 17 bits[0], programs frequently require the use of
-ffunction-sections. It would be preferable if (on hppa or otherwise)
On 06.08.2010 00:58, brian m. carlson wrote:
On Thu, Aug 05, 2010 at 10:59:18PM +0200, Matthias Klose wrote:
On 08.07.2010 01:42, brian m. carlson wrote:
Package: gcc-4.4
Version: 4.4.4-6
Severity: wishlist
Because the ELF ABI for hppa requires relative jumps which are limited
to 17 bits[0
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
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
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
On 02.03.2011 07:36, Konstantinos Margaritis wrote:
On 2 March 2011 03:34, Matthias Klose d...@debian.org 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
On 02.03.2011 17:54, Martin Guy wrote:
On 2 March 2011 02:34, Matthias Klose d...@debian.org 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 in case this would mean
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 other
On 04/26/2011 05:31 PM, Konstantinos Margaritis wrote:
On 26 April 2011 18:03, Matthias Klosed...@debian.org 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?
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, i386
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-hppa-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
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't have plans to change any other architectures
Am 28.03.2013 13:02, schrieb John David Anglin:
On 28-Mar-13, at 1:25 AM, Matthias Klose wrote:
Am 26.03.2013 23:14, schrieb Dave Anglin:
Package: gcc-4.8
Version: 4.8.0-1
Severity: normal
There is a config problem building the hppa64 package:
David, I'm applying this patch, however I
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.
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.org/gcc-4.8
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 please,
until the 4.8 one
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 time
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
Control: tags -1 + moreinfo
Afaics, the situation didn't change. There is nobody committing to work on the
toolchain for these architectures. At least for release architectures the
alternative is to drop the port unless somebody wants to maintain the toolchain
for this port. This is the current
Am 02.12.2013 23:20, schrieb Hiroyuki Yamamoto:
Hi,
I don't know whether it is appropriate that I remark,
I have no objection to moving to gcc-4.8 on ppc64, too.
this is not a question about any objections, but about a call to the ppc64
porters if they are able to maintain such a port in
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.9suite=experimental
These are already fixed in the vcs.
- fixed the gospec.c ftbfs on archs without ld.gold
- fixed the g++
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
Control: tags -1 - patch
Am 18.04.2014 08:19, schrieb Helmut Grohne:
Package: src:gcc-4.8
Version: 4.8.2-19
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
I noticed that a DEB_TARGET_ARCH=hppa build with DEB_CROSS_NO_BIARCH=yes
would try to build for hppa64
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
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, Matthias Klose d...@debian.org wrote:
With gcc-4.9 now available in testing, it is time to prepare for the change
of
the default to 4.9
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-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
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
&
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
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
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
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
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
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
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
Package: src:debugedit
Version: 1:5.0-1
Severity: important
Tags: sid bookworm
X-Debbugs-CC: debian-hppa@lists.debian.org
Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=28598
debugedit shows some test failures on hppa:
Package: src:gcc-12
Version: 12.1.0-5
Severity: important
X-Debbugs-CC: debian-hppa@lists.debian.org
gcc-12 ftbfs on hppa:
libtool: compile: /<>/build/./gcc/xgcc -shared-libgcc
-B/<>/build/./g
cc -nostdinc++ -L/<>/build/hppa-linux-gnu/libstdc++-v3/src
-L/<>/build
1 - 100 of 101 matches
Mail list logo
