work needed on the python2.1 - 2.2 transition
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 due to five serious reports, but doesn't go to testing, because it needs python2.2. This gets difficult ... - out of date packages on some architectures. many on arm, some on ia64, m68k, a few on mips, mipsel, sparc. See below. - we have to wait for the glibc transition to testing, as new binary packages are built. Don't know when this will be ... Maybe all new python related uploads should be urgency medium to not further delay the transition. Matthias PACKAGES NEEDING UPLOADS / WORK postgresql five serious bug reports, depends on python ... python-tal ood the package changed from arch any to all, so excuses still lists this package. sip-qt2 ood m68k listed in excuses, why? other packages depend on sip-qt2 pybliographer ftbfs s390 glibc related problem? reportbug priority problem, should be tagged as pending glimmer ftbfs alpha m68k dependency problem libgnome-vfs0/libgnome-vfs-common pycurl ood m68k not yet built python-gd ood m68k not yet uploaded snappea ood arm m68k mipsel didn't investigate python-qt2 ood m68k ftbfs due to sip-qt2 dependency problem gnumeric ood mipsel no build attempts egenix-mx-base ood arm built, not uploaded python-popy ood arm needs egenix-mx-base be built python-pgsql ood arm needs egenix-mx-base be built python-gtk2 ood mips mipsel / hppa unsatisfiable depends ftbfs, needs config.* update python-ldap ood arm built, not uploaded python-mysqldb ood arm built, not uploaded vtk ood mipsel segfault during build? vtk ftbfs m68k missing build dependency? python-reportlab ood ia64 built, but not uploaded? python-utmp ood ia64 built, but not uploaded? sketch ood ia64 sparc built, but not uploaded? quantlib-python ood arm no build attempts libming ftbfs hppa ia64 preparing NMU (doko) python-opengl ftbfs need to check, if the report is already fixed, but not closed. python-qt ood m68k STATUS WAITING (2002-10-22): 9 mcfoo pyne python-davlib python-stats python-tclink 8 garchiver libmp3hip python-biggles python-unit snappea 7 forg plplot 6 dput libapache-mod-python python-optik 5 pybliographer pycurl 4 python-htmltmpl python-tal 0 ecasound linda python-japanes-codecs vte NEW IN UNSTABLE, NO OLDER PACKAGE IN TESTING subversion subversion-snapshot wxwindows2.3 sqlrelay buggy, package maintainer does not respond ldaptor buggy gnue-forms buggy due to python2-base dependency
status of report #151886? / feedback
[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 be simply incorporated. willy would be a good target. I'm going to be out of town for a couple of weeks, but (if it's still pending) I'd be happy to help when I get back. Camm, another try with the current (20021227) gcc-snapshot package (now branched to become gcc-3.3 sometime).
Re: Bug#151886: status of report #151886? / feedback
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 for this to get fixed any time soon. Gcl can build its own bfd library, so patches here can be simply incorporated. willy would be a good target. I'm going to be out of town for a couple of weeks, but (if it's still pending) I'd be happy to help when I get back. Camm, another try with the current (20021227) gcc-snapshot package (now branched to become gcc-3.3 sometime). I forget which of the several gcc difficulties I'd been having with GCL on hppa to which this note referred. yes, the report got long ... In any case, I see I'm going to have a problem with 3.3: /home/camm/usr/lib/gcc-snapshot/lib/gcc-lib/hppa-linux/3.3/include/varargs.h:4:2: #error GCC no longer implements varargs.h. /home/camm/usr/lib/gcc-snapshot/lib/gcc-lib/hppa-linux/3.3/include/varargs.h:5:2: #error Revise your code to use stdarg.h. Fixing this will take considerable effort. Is there a work around to get varargs under 3.3? I don't think so: 2002-07-15 Zack Weinberg [EMAIL PROTECTED] * ginclude/varargs.h: Replace with stub which issues #error. * ginclude/stdarg.h: __builtin_stdarg_start is renamed __builtin_va_start. [...] * doc/invoke.texi, doc/sourcebuild.texi, doc/tm.texi, doc/trouble.texi: Remove references to GCC-provided varargs.h.
gcc-3.2 - gcc-3.3 transition on hppa
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 binaries go to testing? The packaging for 3.3 can be found in the Debian CVS. Currently, the following libstdc++ packages are built: libstdc++5 libstdc++5-3.3-dbg libstdc++5-3.3-pic libstdc++5-3.3-dev The packages are renamed from the 3.2 based packages to allow non-conflicting installation of gcc-3.2 and gcc-3.3. Keeping the libstdc++5 name works for all archs, which do not change in configuration between 3.2 and 3.3. So what to do on hppa? m68k's 3.3 is configured to use sjlj exceptions (same as 3.2), so this is now problem. Matthias
Re: gcc-3.2 - gcc-3.3 transition on hppa
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 the recompilation before 3.2 based binaries go to testing? The packaging for 3.3 can be found in the Debian CVS. You can get test packages from http://ftp-master.debian.org/~doko/gcc-3.3/ Matthias PS: Someone (?) posted scripts to setup an apt-able archive for more than one architecture/release. However I forgot where I have seen these ...
Re: gcc-3.2 - gcc-3.3 transition on hppa
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, how to handle it? Currently 3.2 is in unstable only. Would you want to start the recompilation before 3.2 based binaries go to testing? The packaging for 3.3 can be found in the Debian CVS. You can get test packages from http://ftp-master.debian.org/~doko/gcc-3.3/ well this is not looking good. after installing these in a freshly built sarge chroot, all c++ programs stop working (well, i've only tried two -- apt and fakeroot) You can find updated packages at http://ftp-master.debian.org/~doko/gcc-3.3/hppa/ checked building bash (fakeroot) and upgrading an unstable chroot (apt). (btw, small packaging detail, but the libstdc++*-dev package above cannot be installed cleanly because it overwrites things in the current 3.2 package) There is still one conflict for libstdc++5-dev (= 1:3.2.3-0pre3), so please install libstdc++5-dev (1:3.2.3-0pre4) first. Matthias
gcc fails to build using binutils-2.14.90.0.1
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 -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_mulI -xassembler-with-cpp -c ../../src/gcc/config/pa/milli64.S -o libgcc/./_mulI.o ../../src/gcc/config/pa/milli64.S: Assembler messages: ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): millicode make[5]: *** [libgcc/./_mulI.o] Error 1
parisc boot failure caused by setserial
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 daemon: portmap. Loading the saved-state of the serial devices... Cannot set serial info: Device or resource busy /dev/ttyS0 at 0x0040 (irq = 132) is a 16550A * SYSTEM ALERT ** SYSTEM NAME: gsphppa DATE: 09/24/2003 TIME: 22:05:03 ALERT LEVEL: 7 = reserved REASON FOR ALERT SOURCE: 0 = unknown, no source stated SOURCE DETAIL: 0 = unknown, no source stated SOURCE ID: FF PROBLEM DETAIL: 0 = no problem detail LEDs: RUN ATTENTION FAULT REMOTE POWER ON OFF OFF ON ON LED State: System running normally. 0x007000FF6292 00F0 F000 - type 0 = Data Field Unused 0x5800087000FF6292 6708 18160503 - type 11 = Timestamp 09/24/2003 22:05:03 A: ack read of this entry - X: Disable all future alert messages Anything else skip redisplay the log entry -Choice:Timeout! *
Re: Bug#224200: gcc-3.3 fails to generate EH_FRAME program-header
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 gcc-3.3 is inconsistent with
that of Red Hat's gcc-3.2 when -fexceptions is specified. Example:
On Debian/testing:
$ cat t.c
int main (int argc, char **argv) {
printf (hello\n);
}
$ gcc-3.3 -fexceptions t.c
$ objdump --priv a.out |grep EH
(no output)
On Red Hat 9:
$ cat t.c
int main (int argc, char **argv) {
printf (hello\n);
}
$ gcc -fexceptions t.c
$ objdump --priv a.out |grep EH
EH_FRAME off0x0420 vaddr 0x08048420 paddr 0x08048420 align 2**2
I believe this is a serious problem because it means that a DWARF2
unwinder will not be able to unwind across C code even though it was
compiled with -fexceptions.
Bug#225892: [patch] on hppa build binutils targeted for hppa64
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 step ...
Binary packages currently can be found at
http://cs.tu-berlin.de/~doko/tmp/hppa/
diff -ur binutils-2.14.90.0.7.old/debian/control
binutils-2.14.90.0.7/debian/control
--- binutils-2.14.90.0.7.old/debian/control 2003-12-15 08:25:17.0
+0100
+++ binutils-2.14.90.0.7/debian/control 2003-12-17 22:39:10.0 +0100
@@ -43,6 +43,19 @@
NORMAL USERS SHOULD NOT INSTALL THIS PACKAGE. It's meant only for those
requiring support for reading info from binaries from other architectures.
+Package: binutils-hppa64
+Architecture: hppa
+Depends: ${shlibs:Depends}, binutils (= ${Source-Version})
+Conflicts: binutils-multiarch
+Recommends: libc6-dev
+Suggests: binutils-doc (= ${Source-Version})
+Description: The GNU assembler, linker and binary utilities targeted for
hppa64-linux
+ The programs in this package are used to assemble, link and manipulate
+ binary and object files. They may be used in conjunction with a compiler
+ and various libraries to build programs.
+ .
+ This package is needed to build an 64bit kernel for the 64bit hppa machines.
+
Package: binutils-doc
Section: doc
Architecture: all
diff -ur binutils-2.14.90.0.7.old/debian/rules binutils-2.14.90.0.7/debian/rules
--- binutils-2.14.90.0.7.old/debian/rules 2003-12-15 08:25:17.0
+0100
+++ binutils-2.14.90.0.7/debian/rules 2003-12-17 22:37:07.0 +0100
@@ -19,6 +19,7 @@
p_dev = $(p_bin)-dev
p_mul = $(p_bin)-multiarch
p_doc = $(p_bin)-doc
+p_hppa64 = $(p_bin)-hppa64
pwd := $(shell pwd)
d = debian/tmp
@@ -26,6 +27,7 @@
d_dev = debian/$(p_dev)
d_mul = debian/$(p_mul)
d_doc = debian/$(p_doc)
+d_hppa64 = debian/$(p_hppa64)
install_dir= install -d -m 755
install_file = install -m 644
@@ -44,6 +46,12 @@
MULTI_VERSION = $(VERSION)-multiarch
MULTI_ARGS= MAKEOVERRIDES=VERSION=$(MULTI_VERSION)
+HPPA64_VERSION= $(VERSION)-hppa64
+HPPA64_ARGS = MAKEOVERRIDES=VERSION=$(HPPA64_VERSION)
+hppa64_prefix = usr
+#hppa64_prefix = usr/hppa64-linux
+#hppa64_prefix = usr/lib/hppa64-linux
+
# Use older gcc on m68k until test suite regressions are resolved
@@ -92,10 +100,10 @@
clean: unpatch
$(checkdir)
- -rm -fr builddir-multi builddir-single
+ -rm -fr builddir-multi builddir-single builddir-hppa64
-find . -name \*.gmo -o -name \*~ | xargs rm -f
-rm -f $(pwd)/test-summary
- -rm -fr $(d_bin) $(d_dev) $(d_mul) $(d_doc)
+ -rm -fr $(d_bin) $(d_dev) $(d_mul) $(d_doc) $(d_hppa64)
-rm -rf debian/patched debian/tmp debian/files debian/substvars
@@ -150,8 +158,40 @@
CFLAGS=$(CFLAGS) $(MULTI_ARGS)
touch build-multi-stamp
+
+
+#
+# hppa64 target #
+#
+
+configure-hppa64-stamp: patch-stamp
+ $(checkdir)
+ rm -rf configure-hppa64-stamp \
+ builddir-hppa64
+ mkdir builddir-hppa64
+ cd builddir-hppa64 \
+env CC=$(CC) ../configure \
+ --enable-shared \
+ --prefix=/$(hppa64_prefix) \
+ --build=$(DEB_BUILD_GNU_TYPE) \
+ --host=$(DEB_BUILD_GNU_TYPE) \
+ --target=hppa64-linux
+ $(MAKE) -C builddir-hppa64 configure-host
+ touch configure-hppa64-stamp
+
+build-hppa64-stamp: configure-hppa64-stamp
+ $(checkdir)
+ $(MAKE) -C builddir-hppa64/bfd headers
+ $(MAKE) -C builddir-hppa64 \
+ CFLAGS=$(CFLAGS) $(HPPA64_ARGS)
+ touch build-hppa64-stamp
+
+build_stamps = build-single-stamp build-multi-stamp
+ifeq ($(DEB_HOST_ARCH),hppa)
+ build_stamps += build-hppa64-stamp
+endif
build: build-stamp
-build-stamp: build-single-stamp build-multi-stamp
+build-stamp: $(build_stamps)
touch build-stamp
@@ -160,7 +200,11 @@
# install target #
##
-install: install-stamp
+install_stamps = install-stamp
+ifeq ($(DEB_HOST_ARCH),hppa)
+ install_stamps += install-hppa64-stamp
+endif
+install: $(install_stamps)
install-stamp: checkroot build-stamp
$(checkdir)
@@ -183,7 +227,7 @@
: # Work around bug in 2.14.90.0.7 which caused as info and
: # manpages to not be installed.
make -C builddir-single/gas/doc \
- mandir=$(pwd)/$(d_bin)/usr/share/man \
+ mandir=$(pwd)/$(d_bin)/usr/share/man \
infodir=$(pwd)/$(d_doc)/usr/share/info install-info-am
install-am
running gcc testsuite triggers ongoing page faults
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 archives (kernel-image-2.4.21-64-smp_pa7.3) Jan 11 06:42:49 pampa kernel: do_page_fault() pid=13367 command='expect' type=15 address=0x4abfccfe Jan 11 06:42:49 pampa kernel: vm_start = 0x40353000, vm_end = 0x40355000 Jan 11 06:42:49 pampa kernel: Jan 11 06:42:49 pampa kernel: YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI Jan 11 06:42:49 pampa kernel: PSW: 0100 Not tainted Jan 11 06:42:49 pampa kernel: r00-03 40336510 4033655c fffa Jan 11 06:42:49 pampa kernel: r04-07 40336570 1008 1002 0063 Jan 11 06:42:49 pampa kernel: r08-11 00021148 00207a8c 0006 5438 Jan 11 06:42:49 pampa kernel: r12-15 40050a6c 40050a78 00021618 0001 Jan 11 06:42:49 pampa kernel: r16-19 0001 403349c8 Jan 11 06:42:49 pampa kernel: r20-23 00207bb8 0ab50a94d694 402af66a 002067a8 Jan 11 06:42:49 pampa kernel: r24-27 400a8ec2 000lt() pid=13367 command='expect' type=15 address=0x4abfccfe Jan 11 06:42:49 pampa kernel: vm_start = 0x40353000, vm_end = 0x40355000 Jan 11 06:42:49 pampa kernel: Jan 11 06:42:49 pampa kernel: YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI Jan 11 06:42:49 pampa kernel: PSW: 0100 Not tainted Jan 11 06:42:49 pampa kernel: r00-03 40336510 4033655c fffa Jan 11 06:42:49 pampa kernel: r04-07 40336570 1008 1002 0063 Jan 11 06:42:49 pampa kernel: r08-11 00021148 00207a8c 0006 5438 Jan 11 06:42:49 pampa kernel: r12-15 40050a6c 40050a78 00021618 0001 Jan 11 06:42:49 pampa kernel: r16-19 0001 403349c8 Jan 11 06:42:49 pampa kernel: r20-23 00207bb8 0ab50a94d694 402af66a 002067a8 Jan 11 06:42:49 pampa kernel: r24-27 400a8ec2 0ab50a94d690 0ab50a94d694 00020dd4 Jan 11 06:42:49 pampa kernel: r28-31 0ab54abfccfa 40336584 faf06a80 0004 Jan 11 06:42:49 pampa kernel: sr0-3 00d28480 00d28480 00d28480 Jan 11 06:42:49 pampa kernel: sr4-7 00d28480 00d28480 00d28480 00d28480 Jan 11 06:42:49 pampa kernel: Jan 11 06:42:49 pampa kernel: IASQ: 00d28480 00d28480 IAOQ: 40259043 40259047 Jan 11 06:42:49 pampa kernel: IIR: 0f881094ISR: 00d28480 IOR: 4abfccfe Jan 11 06:42:49 pampa kernel: CPU:1 CR30: 18f5c000 CR31: 8020 Jan 11 06:42:49 pampa kernel: ORIG_R28: 0ab54abfccfa Jan 11 06:42:49 pampa kernel: Jan 11 06:42:49 pampa kernel: do_page_fault() pid=13367 command='expect' type=15 address=0x4abfccfe Jan 11 06:42:49 pampa kernel: vm_start = 0x40353000, vm_end = 0x40355000 Jan 11 06:42:49 pampa kernel: Jan 11 06:42:49 pampa kernel: YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI Jan 11 06:42:49 pampa kernel: PSW: 0100 Not tainted Jan 11 06:42:49 pampa kernel: r00-03 40336510 4033655c fffa Jan 11 06:42:49 pampa kernel: r04-07 40336570 1008 1002 0063 Jan 11 06:42:49 pampa kernel: r08-11 00021148 00207a8c 0006 5438 Jan 11 06:42:49 pampa kernel: r12-15 40050a6c 40050a78 00021618 0001 Jan 11 06:42:49 pampa kernel: r16-19 0001 403349c8 Jan 11 06:42:49 pampa kernel: r20-23 00207bb8 0ab50a94d694 402af66a 002067a8 Jan 11 06:42:49 pampa kernel: r24-27 400a8ec2 0ab50a94d690 0ab50a94d694 00020dd4 Jan 11 06:42:49 pampa kernel: r28-31 0ab54abfccfa 40336584 faf06a80 0004 Jan 11 06:42:49 pampa kernel: sr0-3 00d28480 00d28480 00d28480 Jan 11 06:42:49 pampa kernel: sr4-7 00d28480 00d28480 00d28480 00d28480 Jan 11 06:42:49 pampa kernel: Jan 11 06:42:49 pampa kernel: IASQ: 00d28480 00d28480 IAOQ: 40259043 40259047 Jan 11 06:42:49 pampa kernel: IIR: 0f881094ISR: 00d28480 IOR: 4abfccfe Jan 11 06:42:49 pampa kernel: CPU:1 CR30: 18f5c000 CR31: 8020 Jan 11 06:42:49 pampa kernel: ORIG_R28:
Re: Bug#228421: gcc 3.0.4 generates bad code on Debian 3.0/PARISC
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 unknown
glibc: Version: 2.2.5-11.5
GCC 3.0.4 included in Debian 3.0 generates bad code on PARISC platform. The
original apache 1.3.26 distributed in this port returns lines full of zeroes
in the size field of the files between 1 and 100 MB :
linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05
0.M
patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04
-0.0M
CONTENTS-2.4.20-wt1708-Jun-2003 10:5218k
... and so on.
So I have recompiled 1.3.29 from sources with gcc-3.0.4, and the problem was
exactly the same. Digging through the code, I discovered that for exactly
these files, apache uses a floating point representation for the size, and it
calls ap_rprintf() which is sort of an sprintf(), with (size/1048576.0) as an
argument, and %4.1fM as the format string.
Replacing the format with %4eM gave me something interesting :
linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 8.417643e-53M
patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 1.284430e-57M
CONTENTS-2.4.20-wt1708-Jun-2003 10:5218k
I've read the complete implementation of ap_rprintf(), and it seems correct
to me. But some double arguments are passed as va_args at several places. So
I thought that it could be possible that gcc does not handle this very well.
Then I recompiled only util_script.c and ap_snprintf.c with gcc-3.3.2, not
changing anything else, and apache now reports correct sizes :
linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 30.1M
patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 7.2M
CONTENTS-2.4.20-wt1708-Jun-2003 10:5218k
Now I've found that it's very easy to reproduce. Consider this trivial
program :
#include stdio.h
#include stdlib.h
main() {
printf(%4.1f\n, 1.23456);
}
Now, test it :
# gcc -O2 -o fp-test fp-test.c
# ./fp-test
0.0
# gcc -O1 -o fp-test fp-test.c
# ./fp-test
1.2
# gcc-3.3.2-parisc -O2 -o fp-test fp-test.c
# ./fp-test
1.2
# gcc -v
Reading specs from /usr/lib/gcc-lib/hppa-linux/3.0.4/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,proto,objc
--prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared
--with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long
--enable-nls --without-included-gettext --disable-checking
--enable-threads=posix --with-cpp-install-dir=bin hppa-linux
Thread model: posix
gcc version 3.0.4
# gcc-3.3.2-parisc -v
Reading specs from /usr/lib/gcc-lib/hppa1.1-hp-linux-gnu/3.3.2/specs
Configured with: ../gcc-3.3.2/configure --prefix=/usr --with-gnu-ld
--with-gnu-as --host=hppa1.1-hp-linux-gnu --target=hppa1.1-hp-linux-gnu
--with-cpu=7100LC --enable-languages=c,c++ --disable-nls --disable-locale
--enable-shared --enable-target-optspace
--enable-version-specific-runtime-libs --program-suffix=-3.3.2-parisc
--enable-threads
Thread model: posix
gcc version 3.3.2
So it seems that the work-around simply is to switch back to -O1.
Unfortunately, I tried about 20 -fno-XXX with -O2 to find the culprit,
but I couldn't. And I don't remember how I can dump the -O1 and -O2
equivalents.
I hope I didn't forget anything. At the moment, I don't know if there are
packages other than apache which have been affected by this bug.
Regards,
Willy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: raising severity of reports filed for packages build-depending on gcc-3.2
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 images Bdale, can you or someone else try cmpiling 2.4.26 with GCC 3.3 from untable? Does HPPA still need 3.0 for the kernel? It does not. Most of the hppa kernel team is using either testing or unstable for devel and we have no indication of outstanding gcc bugs affecting kernel binary. Is this true for the 64bit kernels as well? Matthias
Re: raising severity of reports filed for packages build-depending on gcc-3.2
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 software is known to me. Many third party packages still use libstdc++2.x. Matthias
Re: Removing gcc-3.0 from unstable/testing
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 to be needed, I haven't seen third party software referencing this libstdc++ library version). Do we now have no packages that Build-Depend on gcc-3.0 or g++-3.0? There seem to be an extraordinarily large number of packages in testing for hppa that are still linked against libstdc++3. maybe to be a bit clearer, remove it from unstable. then it get's removed from testing, when no more packages reference it in testing. looking at the packages depending on libstdc++3, I see most badly,maintained, outdated packages, so removing these as well is an alternative. the current dependencies in unstable are: libgc6 - don't know why this is still built using 3.0. The boehm-gc sources build fine with 3.3. just filed RC report. gutenbrowser - did depend on qt2, which was removed. #254307. x10 - needs to be rebuilt. #236060. playmp3list - needs to be rebuilt. #236116. npadmin - needs to be rebuilt. #236117. juice - needs to be rebuilt. #236053. flying - needs to be rebuilt. #236046. craft - needs to be rebuilt. #236043. cdindex-client - needs to be rebuilt. #236041. blackbook - needs to be rebuilt. #236040. bbpal - needs to be rebuilt. #236037. abuse-sdl - needs to be rebuilt. #221379.
Re: [parisc-linux] debootstrap failure?
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 I: Retrieving debootstrap.invalid_dists_sid_main_binary-hppa_Packages I: Validating debootstrap.invalid_dists_sid_main_binary-hppa_Packages I: Checking adduser... I: Checking apt... ... I: Retrieving fdutils I: Validating fdutils I: Retrieving findutils I: Validating findutils E: Couldn't download gcc-3.0-base [EMAIL PROTECTED]:~/src$ [EMAIL PROTECTED]:~/src$ apt-cache search gcc-3.0-base gcc-3.0-base - The GNU Compiler Collection (base package) gcc-3.0 was removed from sid. make sure you use debootstrap 0.2.44 or later. Matthias
Re: [parisc-linux] new debian binutils-hppa64, r=2.15-7 pb?
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 recognized: File format not recognized What's my mistake? It probably tries hppa64-linux-*, and then falls back to *. To fix: ( cd /usr/bin for i in hppa64-linux-gnu-*; do j=`echo $i | sed -e 's/-gnu//'`; sudo ln -s $i $j; done ) Cool that works (obviously after a make clean ;-) that should be fixed after the next gcc-defaults upload. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321785: fakeroot: segfaults on [hppa]
--j79F1xXV029481.1123599719/bolero.cs.tu-berlin.de-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321785: fakeroot: segfaults on [hppa]
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 a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
glibc binary NMU for hppa, built with gcc-3.4
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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc binary NMU for hppa, built with gcc-3.4
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 already happens with 4.0 on m68k-linux). $ gdb .libs/gcj-dbtool GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as hppa-linux...Using host libthread_db library /lib/libthread_db.so.1. (gdb) set args -n foo.db (gdb) run Starting program: /scratch/packages/gcc/snap/gcc-snapshot-20050919/build/hppa-linux-gnu/libjava/.libs/gcj-dbtool -n foo.db [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4227)] [New Thread 32769 (LWP 4230)] [New Thread 16386 (LWP 4231)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4227)] 0x41809c14 in _Unwind_Resume_or_Rethrow () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 (gdb) bt #0 0x41809c14 in _Unwind_Resume_or_Rethrow () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #1 0x4180aed0 in _Unwind_Find_FDE () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #2 0x41995ccc in dl_iterate_phdr () from /lib/libc.so.6 #3 0x4180aa6c in _Unwind_Find_FDE () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #4 0x41806f38 in _Unwind_FindEnclosingFunction () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #5 0x418085d4 in _Unwind_Backtrace () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #6 0x40ae1004 in _Jv_StackTrace::GetStackTrace () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #7 0x40b16028 in java::lang::VMThrowable::fillInStackTrace () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #8 0x40d58e84 in java::lang::Throwable::fillInStackTrace () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #9 0x40d58f78 in java::lang::Throwable::Throwable () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #10 0x40d58fb0 in java::lang::Throwable::Throwable () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #11 0x40d5908c in java::lang::Exception::Exception () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #12 0x40d590d4 in java::lang::ClassNotFoundException::ClassNotFoundException () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #13 0x40d59100 in java::lang::ClassNotFoundException::ClassNotFoundException () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #14 0x40d91414 in java::net::URLClassLoader::findClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #15 0x40b2a178 in gnu::gcj::runtime::BootClassLoader::bootLoadClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #16 0x40b15f30 in java::lang::VMClassLoader::loadClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #17 0x40b0d738 in _Jv_FindClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #18 0x40acd64c in _Jv_FindClassFromSignature () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #19 0x40ae20ec in _Jv_Linker::resolve_field () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #20 0x40ae4250 in _Jv_Linker::ensure_class_linked () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #21 0x40ae4400 in _Jv_Linker::wait_for_state () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #22 0x40b0c720 in java::lang::Class::initializeClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #23 0x40b27df0 in gnu::gcj::convert::BytesToUnicode::getDecoder () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #24 0x40b13c50 in java::lang::String::init () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #25 0x40d6d71c in java::lang::String::String () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #26 0x40acddac in JvConvertArgv () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #27 0x40acf008 in _Jv_RunMain () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #28 0x40acf24c in _Jv_RunMain () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #29 0x40acf278 in JvRunMain () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #30 0x418a2664 in __libc_start_main () from /lib/libc.so.6 #31 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #32 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #33 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #34 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #35 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #36 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #37 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #38 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #39 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #40 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 [gdb hangs here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc binary NMU for hppa, built with gcc-3.4
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gcc-hppa64 compilers
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? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: gcj can't make shared libs on hppa
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 [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 6962)] [New Thread 32769 (LWP 6965)] [New Thread 16386 (LWP 6966)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 6962)] linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3) at unwind-dw2-fde.c:776 776 unwind-dw2-fde.c: No such file or directory. in unwind-dw2-fde.c (gdb) bt #0 linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3) at unwind-dw2-fde.c:776 #1 0x400af174 in linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3) at unwind-dw2-fde.c:794 Previous frame identical to this frame (corrupt stack?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364231: [parisc-linux] Re: Bug#364231: exception catching
[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 double libgcc_s problem. Then, you must build *eveything* for hppa with gcc-4.1 or later. Unfortunately, there's an ABI break. Mixing libraries compiled with 4.0 or earlier with libraries compiled with 4.1 or later is just going to cause unnecessary problems. 3.3 uses libstdc++.so.5, so you avoid the double libgcc_s problem building GMP. However, you still have the ABI change affecting the passing and return of complex types. At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any other gcc libraries built with 4.1 or later need glibc built with 4.1 to function correctly because of the various complex functions in the math library. I think there's a dynamic loader bug here as well. I'm just guessing but I think the double libgcc_s problem causes a problem with the handling of .eh_frame data. Ok, coming back to the question of the system compiler on hppa for etch. Assuming that hppa does want to do that: - is glibc buildable with gcc-4.1 on hppa? - libstdc++6 would need to conflict with libgcc2, which seems to be doable, but then rules out g++-3.4 and g++-4.0 as a fallback solution, where g++-4.1 fails. - libgfortran did have a soname change, so nothing needs to be done. - is libffi hit by the ABI change as well? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364819: gij-4.1: bus error on hppa
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 this documented somewhere, so that you even have a chance to configure a machine like a buildd? we can disable rebuilding the jar file using the interpreter as a workaround. I'll look at it Monday evening when I'm back. FWIW, gij-4.1 also produces unaligned traps when building db4.4 4.4.20-4 on Alpha. so did gij-4.0? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#342545: qt-x11-free FTBFS on hppa (again)
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 libgcc4. Matthias Christopher Martin writes: reopen 342545 2.3.6-15 severity 342545 grave stop Unfortunately, the qt-x11-free FTBFS on hppa has re-occurred: http://buildd.debian.org/fetch.php?pkg=qt-x11-freever=3%3A3.3.6-3arch=hppastamp=1153689954file=logas=raw The error is exactly the same as before: /build/buildd/qt-x11-free-3.3.6/bin/uic -L /build/buildd/qt-x11-free-3.3.6/plugins pixmapfunction.ui -o pixmapfunction.h make[4]: *** [pixmapfunction.h] Bus error Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#342545: qt-x11-free FTBFS
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 that libglu1-mesa could have anything to do with the failure in question. libglu1-mesa should not be a dependency of the tool that's failing with SIGBUS in the build log. I would suggest that someone should investigate this further and get a clear answer on the nature of the bug, because I really don't buy that libgcc skew is to blame. Fair enough, but before I take off for the weekend, I'm sending this report back to libgcc2, since it seems to have been established long ago that this isn't a Qt bug, and it really should be assigned to something in the toolchain. I note that, for a time, the problem was thought to be in glibc, so perhaps the glibc team would again be worth consulting. Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel build dependency on gcc-4.0?
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]
GCC versions on hppa for etch
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 subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libgcc2 rdepends on hppa
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 tora wdq2wav xshisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gnat-4.1/gcj-4.1 manual builds needed on alpha, arm, m68k, mips, mipsel, s390, sparc
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 from etch - fetch gnat-4.1 from etch - dpkg -x gnat-4.1_4.1.1-22_*.deb - rm -rf usr/lib/gcc/*/4.1.3 - tar cf - usr | (cd /; tar xfv -) - ln -sf ../4.1.2/gnat1 /usr/lib/gcc/$arch-linux-gnu/4.1/gnat1 - ln -sf ../4.1.2/adalib /usr/lib/gcc/$arch-linux-gnu/4.1/adalib - ln -sf ../4.1.2/adainclude /usr/lib/gcc/arch-linux-gnu/4.1/adainclude - build with dpkg-buildpackage -b -B -d (ignoring the gnat-4.1 b-d) - undo at least the symlinks in the chroot, or throw away the chroot gcj-4.1 (alpha arm m68k mips mipsel s390 sparc): - needs gcc-4.1_4.1.2 (not yet built on arm and m68k) - work in a sid chroot - install gcj-4.1-base libgcj7-0 libgcj7-jar libgcj7-dev libgcj7-awt gij-4.1 from etch - install other b-d's from sid - build as an extra check, build the package with itself (although this will be done with the next uploads anyway). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc is broken because of gcc
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 then build glibc. Glibc build is ok now. I think the hppa toolchain can move on and build the glibc-2.5-11 and then rebuild the portmap and all pie executable (pfeww... what a bug chain). Seb diff -r -u -b -B -w gcc-4.1-4.1.2-12/debian/changelog gcc-4.1-4.1.2-12+b1/debian/changelog --- gcc-4.1-4.1.2-12/debian/changelog 2007-06-13 22:34:38.0 +0200 +++ gcc-4.1-4.1.2-12+b1/debian/changelog 2007-06-13 12:44:48.0 +0200 @@ -1,3 +1,9 @@ +gcc-4.1 (4.1.2-12+b1) unstable; urgency=low + + * Revert 20218 patch that breaks gcc + + -- Sebastien Bernard [EMAIL PROTECTED] Wed, 13 Jun 2007 12:44:07 +0200 + gcc-4.1 (4.1.2-12) unstable; urgency=high * i386-biarch.dpatch: Update for the backport for PR target/31868. diff -r -u -b -B -w gcc-4.1-4.1.2-12/debian/rules.patch gcc-4.1-4.1.2-12+b1/debian/rules.patch --- gcc-4.1-4.1.2-12/debian/rules.patch 2007-06-13 22:34:38.0 +0200 +++ gcc-4.1-4.1.2-12+b1/debian/rules.patch2007-06-13 12:45:06.0 +0200 @@ -41,8 +41,6 @@ fastjar-version \ fastjar-doc \ libstdc++-doxygen \ - pr20218 \ - pr20218-mips \ pr31868 \ arm-libffi \ libffi-backport \ @@ -112,10 +110,6 @@ debian_patches += pr25524-doc pr26885-doc gcc-4.1-x86-blended-doc libjava-backport-updates2 endif -ifneq (,$(filter $(DEB_TARGET_ARCH), amd64 i386 powerpc ppc64 sparc s390)) - debian_patches += pr20218 -endif - ifeq ($(with_libffi),yes) debian_patches += \ libffi-configure ___ parisc-linux mailing list [EMAIL PROTECTED] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
GCC trunk 20070630
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: hppa-linux-gnu gcc version 4.3.0 20070630 (experimental) Native configuration is hppa-unknown-linux-gnu === g++ tests === Running target unix FAIL: g++.dg/compat/eh/ctor1 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: g++.dg/compat/eh/new1 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: g++.dg/compat/eh/template1 cp_compat_x_tst.o-cp_compat_y_tst.o execute WARNING: program timed out. FAIL: g++.dg/compat/eh/unexpected1 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: g++.dg/compat/init/array5 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_y_tst.o compile, (internal compiler error) UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_x_tst.o-cp_compat_y_tst.o link UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: g++.dg/cpp0x/variadic73.C execution test FAIL: g++.dg/eh/alias1.C execution test FAIL: g++.dg/eh/cond1.C execution test FAIL: g++.dg/eh/ctor1.C execution test FAIL: g++.dg/eh/elide1.C execution test FAIL: g++.dg/eh/elide2.C execution test FAIL: g++.dg/eh/forced1.C execution test FAIL: g++.dg/eh/forced2.C execution test FAIL: g++.dg/eh/gcsec1.C execution test FAIL: g++.dg/eh/new1.C execution test FAIL: g++.dg/eh/registers1.C execution test FAIL: g++.dg/eh/spbp.C execution test FAIL: g++.dg/eh/template1.C execution test WARNING: program timed out. FAIL: g++.dg/eh/unexpected1.C execution test FAIL: g++.dg/eh/weak1.C execution test FAIL: g++.dg/ext/cleanup-10.C execution test FAIL: g++.dg/ext/cleanup-11.C execution test FAIL: g++.dg/ext/cleanup-8.C execution test FAIL: g++.dg/ext/cleanup-9.C execution test FAIL: g++.dg/ext/visibility/ms-compat-1.C scan-hidden hidden[ \\t_]*__ZTI1T FAIL: g++.dg/init/array16.C execution test FAIL: g++.dg/init/array5.C execution test FAIL: g++.dg/init/ctor1.C execution test FAIL: g++.dg/init/ref9.C execution test FAIL: g++.dg/opt/pr23478.C execution test XPASS: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not offset: -4B XPASS: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not x\\[5\\] XPASS: g++.dg/warn/Warray-bounds.C (test for warnings, line 22) XPASS: g++.dg/warn/Warray-bounds.C (test for excess errors) FAIL: g++.old-deja/g++.abi/cxa_vec.C execution test FAIL: g++.old-deja/g++.eh/catch11.C execution test FAIL: g++.old-deja/g++.eh/catch12.C execution test FAIL: g++.old-deja/g++.eh/catch3.C execution test FAIL: g++.old-deja/g++.eh/catch3p.C execution test FAIL: g++.old-deja/g++.eh/catch4.C execution test FAIL: g++.old-deja/g++.eh/catch4p.C execution test FAIL: g++.old-deja/g++.eh/catch5.C execution test FAIL: g++.old-deja/g++.eh/catch5p.C execution test FAIL: g++.old-deja/g++.eh/catch6.C execution test FAIL: g++.old-deja/g++.eh/catch6p.C execution test FAIL: g++.old-deja/g++.eh/catch7.C execution test FAIL: g++.old-deja/g++.eh/catch7p.C execution test FAIL: g++.old-deja/g++.eh/catch8.C execution test FAIL: g++.old-deja/g++.eh/catch8p.C execution test FAIL: g++.old-deja/g++.eh/catch9.C execution test FAIL: g++.old-deja/g++.eh/catch9p.C execution test FAIL: g++.old-deja/g++.eh/cleanup1.C execution test FAIL: g++.old-deja/g++.eh/cleanup2.C execution test FAIL: g++.old-deja/g++.eh/flow1.C execution test FAIL: g++.old-deja/g++.eh/fntry1.C execution test FAIL: g++.old-deja/g++.eh/new2.C execution test FAIL: g++.old-deja/g++.eh/pdel1.C execution test FAIL: g++.old-deja/g++.eh/rethrow1.C execution test FAIL: g++.old-deja/g++.eh/rethrow2.C execution test FAIL: g++.old-deja/g++.eh/rethrow4.C execution test FAIL: g++.old-deja/g++.eh/rethrow5.C execution test FAIL: g++.old-deja/g++.eh/spec1.C execution test WARNING: program timed out. FAIL: g++.old-deja/g++.eh/spec2.C execution test FAIL: g++.old-deja/g++.eh/spec3.C execution test FAIL: g++.old-deja/g++.eh/terminate1.C execution test FAIL: g++.old-deja/g++.mike/eh10.C execution test FAIL: g++.old-deja/g++.mike/eh16.C execution test FAIL: g++.old-deja/g++.mike/eh17.C execution test FAIL: g++.old-deja/g++.mike/eh18.C execution test FAIL: g++.old-deja/g++.mike/eh2.C execution test FAIL: g++.old-deja/g++.mike/eh23.C execution test FAIL: g++.old-deja/g++.mike/eh29.C execution test FAIL: g++.old-deja/g++.mike/eh3.C execution test WARNING: program timed out. FAIL: g++.old-deja/g++.mike/eh33.C execution test FAIL: g++.old-deja/g++.mike/eh39.C execution test FAIL: g++.old-deja/g++.mike/eh40.C execution test FAIL: g++.old-deja/g++.mike/eh41.C execution test FAIL: g++.old-deja/g++.mike/eh44.C execution test FAIL: g++.old-deja/g++.mike/eh5.C execution test WARNING: program timed out. FAIL: g++.old-deja/g++.mike/eh50.C execution test WARNING: program timed out. FAIL: g++.old-deja/g++.mike/eh51.C execution test FAIL:
Re: [parisc-linux] GCC trunk 20070630
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 on other archs as well (at least 20070702). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GCC 4.2 transition
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. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux32 personality config.guess
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] linux32 personality config.guess
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 PROTECTED]
[alpha, hppa] GCC-4.3 as the default compilers for lenny?
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 errors on hppa (either 4.2 or 4.3). Please could the porter teams give some advice (drop the architecture for the lenny release, use another (which?) compiler version, drop gcj/java support, or fix things)? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [alpha, hppa] GCC-4.3 as the default compilers for lenny?
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 a random HelloWorld program using the interpreter. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [alpha, hppa] GCC-4.3 as the default compilers for lenny?
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 (1.5) did work. Now that a working runtime is required for the compiler makes things different. Please try to run a random HelloWorld program using the interpreter. I'm not at all interested in gij/gcj. Why do we require that all languages be functional for a gcc release? This is a difficult goal to meet. I'll let the release team answer this question. IMO we should require a port to support some kind of java runtime. Is there any chance to get the IcedTea Zero port working for hppa, or get the hpux java support be ported to OpenJDK? As the hppa-linux libc-ports maintainer I *am* interested in seeing the list of regressions you have and commenting on them. Please wait for the feedback from Aurelian. Also note that the hppa-linux list is [EMAIL PROTECTED] thanks for the hint. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#472969: gcc-4.2: Depends on Tcl/Tk 8.3 which is subject to removal
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: important Hi! Your package currently build-depend on expect-tcl8.3 which in turn depends on tcl8.3. Debian Tcl/Tk packaging team is about to remove tcl8.3 (and tk8.3) from Debian because it's really outdated (more than five years) and imposes unnecessary burden to Debian Security Team [1]. Please, replace expect-tcl8.3 build-dependency by expect build-dependency. If it leads to a regression, report it. It's better to fix Tcl/Tk 8.4 than to keep Tcl/Tk 8.3 around. [1] http://wiki.debian.org/Teams/DebianTclTk/Announce -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dropping gcc-3.4 on hppa for the release
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 that we can remove libgcc2 (built from the gcc-4.0 sources) from the release. If you're a package maintainer of one of the packages qemu, smarteiffel, stegdetect, wordtrans, prc-tools, please consider uploading this package with a build dependency on gcc-3.4 [!hppa] and explicitely failing the build on the hppa architecture. [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gcc-3.4;[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Approval to upload gcc-defaults 1.70?
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 in testing and has RC bugs. I've committed the necessary change in the Subversion repo but I will not upload without approval. So, is it OK to upload now? please wait until Tue. the immediate need for the upload apparently was worked around by hinting both gnat-4.2 and gnat-4.3 into testing. I'd like to re-ask the hppa porters, if they want to make 4.3 the default for lenny. A short notice from the d-r team about by-passing RC reports would be appreciated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Approval to upload gcc-defaults 1.70?
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. Has anyone built a kernel with this version of gcc-4.3 and tried it? Can I apt-get install -t sid gcc-4.3 on my hybrid system and get the right version? gcc-4.3 and gcc-4.3-hppa64 are both available in the same version in testing and unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages
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-dev packages; there is no package build-depending on libc6-hppa64-dev, but we need these packages to run the testsuites for binutils and gcc-4.X. Currently these packages are completely untested, although used to build the 64bit flavour of the kernel on hppa. There is no upstream support for 64-bit glibc on hppa, so this bug is currently a wontfix. Please provide us a patch. that's fine. in this case we should drop support for hppa for lenny. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#509555: icon ftbfs on hppa
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 package built manually? Please update the package such that it doesn't fail to build on the buildd. gcc -c rswitch.s rswitch.s: Assembler messages: rswitch.s:9: Error: Unknown opcode: `coswitch' rswitch.s:14: Error: Missing function name for .PROC [...] -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
OpenJDK Cacao GCJ Java defaults in unstable
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:
- openjdk-6-jre-zero: built on amd64 and i386. This is the JVM used by
default on the non-hotspot archs (armel, alpha, s390, mips, mipsel,
powerpc, m68k?). Maybe useful for debugging issues with the zero JVM on
archs which are more accessible.
- icedtea-6-jre-cacao: built on alpha, armel, mips, mipsel, s390, i386,
amd64, powerpc). The Cacao JVM and JIT is not yet feature complete
compared to the hotspot JVM, but is much faster than the Zero JVM
and offers an alternative on platforms which don't have the Hotspot
JVM.
The additional JVM's can be called with
java [-cacao|-zero]
or for the java tools with
tool name [-J-cacao|-J-zero]
This is currently a Debian/Ubuntu only option; integration into IcedTea is in
progress.
To make a JVM the default, make it the first one in /etc/java-6-openjdk/jvm.cfg.
GCJ is still the work horse to build and bootstrap OpenJDK. IMO it still does
make sense to keep the '-gcj' packages for software which is known to work with
GCJ. I plan to have a recent GCJ-4.x release for the next Debian release.
Once openjdk-6 moves to testing, I propose to change the default in the
default-{jre,jdk} packages to point to the openjdk-6 packages. This works well,
except for one thing: packages will be built with -source 1.6 by default, which
makes the resulting .class/.jar files unusable with older java versions (1.4 and
1.5). I would like to propose a change in the Debian java policy, that java
packages must be built for the version which is sufficient for a sucessful
build. The changes are trivial; I already did check in changes for ant and ant
build- and runtime dependencies into the debian-java svn.
There is currently work-in-progress to extend the Zero JVM with a JIT (called
shark). This is still experimental work, currently requires llvm-2.4 (unstable
has 2.5). I would welcome feedback from port maintainers about zero/shark.
Please consider to join the IcedTea mailing list.
Matthias
PS: I would appreciate some help with openjdk in Debian; the current maintainer
team is MIA or inactive.
--
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hppa in danger of being ignored for testing migration and eventual removal
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 lately? GCJ-4.4 works fine on hppa, currently waiting in NEW ... so if you do want to see this resolved, please help with getting this accepted. Note that this doesn't work very well with NPTL (Ubuntu karmic), so please make sure that this continues to work with an glibc update. OpenJDK is non-trivial. Andrew Haley did have a look at this and came to the conclusion that the byte code interpreter for the zero port needs porting for archs with upward growing stacks. Maybe hotspot is an alternative? Did somebody ask HP to open-source their hotspot port of sun-java5? Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
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, Neil McGovern wrote: Hi, As mentioned previously[0], the release team haven't been happy with the state of the HPPA port in Debian. After the release team meeting[1], it has been decided that unfortunatly HPPA will not be supported for Squeeze. This was after careful consideration, and wasn't an easy decision. This means that ftpmasters will be asked to remove HPPA from testing and unstable from the 30th June. It is suggested that HPPA porters may wish to consider using debian-ports.org if they wish to continue with the port. Regards, Neil McGovern [0] http://lists.debian.org/debian-release/2009/04/msg00299.html Carlos O'Donnell asked some questions in response to [0] and I never saw any response. Can an attendee of the above meeting please reply this email from Carlos? http://lists.debian.org/debian-release/2009/04/msg00303.html Note that it's wrong to assume we will come with the answers. I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. +1. dropping hppa as a release architecture was not communicated by the release team at all. I did spend some time to get gcj / default-jdk working on hppa, and some money (buying a new disk for a hppa machine) to help this port. The time and the money could have spent better, if d-r would have better communicated about their intent. hppa is not in a good shape, but there are other architectures which are not better (sparc, mips*) from a toolchain point of view. what about these? there are issues pointed out and not addressed like the -dev / -headers packages built as binary independent packages just to save disk space, which have an impact on slow architectures, and which are not addressed by the release team. would the release team mind addressing these real issues, or should we drop slow architectures as well? Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
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 that it's wrong to assume we will come with the answers. I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. +1. dropping hppa as a release architecture was not communicated by the release team at all. I did spend some time to get gcj / default-jdk working on hppa, and some money (buying a new disk for a hppa machine) to help this port. The time and the money could have spent better, if d-r would have better communicated about their intent. There are issues with the hppa port where the release team considered dropping it since 2005 communicated to the porter list... hppa is not in a good shape, but there are other architectures which are not better (sparc, mips*) from a toolchain point of view. what about these? I'm not aware of current toolchain issues on sparc and the issues on mips* still seem to be manageable, no? sparc-biarch defaulting to 32bit isn't supported by upstream; there are requests to move to v9 optimization by default, which requires some work in the compiler. I don't plan to update this for upcoming GCC versions, and there's no interest by upstream to help with this kind of setup. You can't buy v8 software for years now, but afaik all our machines run 64bit kernels. Maybe it's time to acknowledge this, remove sparc from the list of release architectures and go on with sparc64? there are currently binutils issues outstanding, reported upstream. plus the non-availability of developer machines seems to be an issue. Sadly we don't have the mips support for squeeze as we had for lenny. there are issues pointed out and not addressed like the -dev / -headers packages built as binary independent packages just to save disk space, which have an impact on slow architectures, and which are not addressed by the release team. would the release team mind addressing these real issues, or should we drop slow architectures as well? Well, this Packages issue is clearly a responsability from the FTP Team and the Release Team would indeed be very happy to have that resolved. So it seems to be ok to ignore an issue, if you can work around it? Fine, then I'll build all compiler front ends from one source again. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: openjdk-6 6b14-4 built but not uploaded
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 openjdk support on mips? Scheduled for upload now. Do you think the failure on hppa was temporary or is there a bug to be filed? thanks! No, it needs porting work (the implementation makes the assumption that the stack always grows downwards; unknown if there are other issues). Andrew Haley did look at it. For now nobody was interested in working on the port. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
any objections from port maintainers to make gcc-4.4 the default?
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 the default java compiler for all architectures except hurd(?), kfreebsd(?) and hppa. hppa already defaults to 4.4, what about the hurd and kfreebsd? Ada will still stay at 4.3 until Ludovic is ready to switch the default to 4.4. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-tcltk-devel] Tcl/Tk plans for squeeze
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, 8.4, 8.5 (with 8.4 as a default one). We are planning to: 1) make 8.5 the default version in squeeze; 2) keep 8.4 for those packages which are useful and can't work with 8.5; 3) remove 8.3 from Debian entirely. please provide an expect package built against 8.5 before considering the removal of 8.3, still used for testing on hppa with expect-tcl8.3. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa
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 pthread_attr_setstack() and pthread_attr_getstack() for hppa. HPPA is an architecture under which the stack grows up and the default implementation does not take that into account. The boehm-gc then uses the wrong stack values during garbase collection initialization and thus every gcj built application crashes. I will work with Aurelian on putting out a fixed libc, until then gcj will not work correctly. Sorry about the inconvenience. It appears that the glibc testsuite is self-consistent, and because both set and get functions are affected the glibc tests actually pass. I didn't notice this because I don't normally bootstrap java. Cheers, Carlos. looking at the gcc-4.4 g++/libstdc++ test results I see regressions as well; is this reproducible for you? Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Csound build failure in hppa
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::
$(DEB_SCONS_INVOKE) $(DEB_SCONS_CLEAN_TARGET) $(DEB_SCONS_OPTIONS)
--keep-going --clean || true
rm -f debian/stamp-scons-build
rm -rf .sconf_temp/
rm -f .sconsign.dblite config.log
The cache are .scon*.
As can be seen in the build log, when scons uses a cached value (like in the
install stage), it prints: Checking for foo... (cached) no.
However, in the buildd log the build stage shows no (cached) responses.
Thanks, I hadn't realized that this code was deleting the scons cache.
With this knowlege I went back, and verified a couple of things:
1) Verified that the custom.py (using md5sum) is installed before scons is run.
2) Verified using strace that scons opens custom.py.
3) Verified using a compiler wrapper that the invocation by
configure.CheckHeader() contains the correct include path.
The following is the compiler invocation that configure.CheckHeader()
uses when looking for jni.h.
hppa-linux-gnu-g++ -o .sconf_temp/conftest_26.o -c -fexceptions
-Wno-format -DGNU_GETTEXT -g -fomit-frame-pointer -freorder-blocks
-DLINUX -DPIPES -DUSE_DOUBLE -DHAVE_SOCKETS
-DHAVE_PTHREAD_BARRIER_INIT -DHAVE_SYNC_LOCK_TEST_AND_SET -I. -IH
-I/usr/include/lua5.1 -I/usr/include/tcl -I/usr/include/tcl8.4
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/java-gcj/include
-I/usr/local/include -I/usr/include -I/usr/include
-I/usr/X11R6/include .sconf_temp/conftest_26.cpp
unrelated: including both -I/usr/lib/jvm/default-java/include
-I/usr/lib/jvm/java-gcj/include looks suspicious.
When I compile this I get:
In file included from .sconf_temp/conftest_26.cpp:2:
/usr/lib/jvm/default-java/include/jni.h:52:20: error: jni_md.h: No
such file or directory
This is why the build fails to detect jni.h, not because the jni.h
file isn't there but because additional header files are missing.
Adding: customCPPPATH.append('/usr/lib/jvm/default-java/include/linux')
to debian/custom.py causes the build to complete successfully. This is
a possible workaround.
not just a workaround; both /usr/lib/jvm/default-java/include and
/usr/lib/jvm/default-java/include/linux have to be included. There is no
garantee that the jni_md.h header is also found in the
/usr/lib/jvm/default-java/include directory.
Matthias
--
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#554574: libstdc++6: apt segfaults on hppa
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 05.11.2009 14:30, Domenico Andreoli wrote: frankly i do not know what to do next, besides trying to rebuild gcc-4.4 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? yes, build started the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to NPTL. I have done some more tests, showing it's a bit more complicated than that. apt-get from stable/testing/unstable: - works with libstdc++6 built against eglibc 2.9 - segfaults with libstdc++6 built against eglibc 2.10.1 Then I tried to rebuild apt against the broken libstdc++6. Surprisingly this new apt-get: - works with libstdc++6 built against eglibc 2.10.1 - segfaults with libstdc++6 built against eglibc 2.9 So in short, it seems that using eglibc 2.10.1 to build libstdc++6 triggers an ABI change on this library. I haven't investigated more for now, I am not sure when I'll have time to do it. This is not surprising, Dave has already pointed out that the debian libstdc++6 testsuite run clearly has an ABI failure e.g. ~~~ FAIL: abi_check ~~~ I don't have a build around, but isn't this due to the one symbol accidentally exported in an earlier libstdc++ version? * Address PR libstdc++/39491, removing __signbitl from the libstdc++6 symbols file on hppa. I'm running a build with --without-cloog/--without-ppl to see if that corrects the testsuite failures. I doubt it; this only enables optimization options which are not turned on by default and not used to build g++/libstdc++. The Debian packages for ppl and cloog and ppl pass the testsuites on all archs. if you know of further tests which could be run in Debian, please let me know. We need to stop allowing packages to build if the testsuite runs aren't clean. yes, or run the testsuite at all (for hppa64-linux-gnu). I'll look into re-enabling checks, but in the past the existing comparision checks are either not working or unreliable for bi/triarch builds. Matthias PS: offline for the next week -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: State of openjdk on hppa
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 hppa. Does anyone know if there is any effort going on to make openjdk-* packages available on hppa. If not then I will have to make java3d a !hppa package. 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. please could one of the hotspot developers sched some light on this, how easy this might to be fix, and if there are other assumptions? thanks, Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: State of openjdk on hppa
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. please could one of the hotspot developers sched some light on this, how easy this might to be fix, and if there are other assumptions? Could you give more detail on where exactly the direction of growth is being assumed? I know there's an accessor in frame that's supposed to describe the direction of growth of the expression stack which is used a few places in the code: // expression stack (may go up or down, direction == 1 or -1) public: intptr_t* interpreter_frame_expression_stack() const; static jint interpreter_frame_expression_stack_direction(); I would think this has to be set correctly for HPPA to work. Is it? It's possible that the C++ interpreter would also need to consult this when pushing values for it to work correctly. thanks for the pointer. zero sets this independently of the architecture. now checking the obvious fix. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FTBFS [hppa]: GC Warning
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 this? -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc0eaa8.7050...@debian.org
Re: FTBFS [hppa]: Assertion `y.isApprox(m*x)' failed.
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 listmas...@lists.debian.org Archive: http://lists.debian.org/4c2934bf.3020...@ubuntu.com
Re: FTBFS [hppa]: Assertion `y.isApprox(m*x)' failed.
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 it as a workaround, unless the default gcc on hppa is changed to 4.3. The bug is when compiling c++ template header files shipped by the -dev package. Alternatively, please advice on how to ensure that all users of libeigen2-dev (a c++ template header only library) uses g++4.3 ? As I don't consider the workaround viable, I'm raising the severity again. I don't care if you consider it viable; there is a workaround, maybe it's painful for you. Please don't raise the severity again yourself but let the release team decide on this. And I hope that the hppa people can provide tests with g++4.5 and snapshots. It is not currently available on the porter boxes. no, you should ask for installation of these packages. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c294130.7090...@debian.org
Re: Bug#588391: gcc-4.4: please automatically use -ffunction-sections when necessary with -fPIC
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) -ffunction-sections were implied by -fPIC when otherwise gcc would generate text sections that are too large. After all, there's really no reason to generate .o files that are, for all practical purposes, useless. It would also make numerous package maintainers and hppa porters very happy, I suspect. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558999#15 as this specific example shows, -ffunction-sections isn't enough, but -mlong-calls is needed. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c5b2626.5090...@debian.org
Re: Bug#588391: gcc-4.4: please automatically use -ffunction-sections when necessary with -fPIC
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], programs frequently require the use of -ffunction-sections. It would be preferable if (on hppa or otherwise) -ffunction-sections were implied by -fPIC when otherwise gcc would generate text sections that are too large. After all, there's really no reason to generate .o files that are, for all practical purposes, useless. It would also make numerous package maintainers and hppa porters very happy, I suspect. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558999#15 as this specific example shows, -ffunction-sections isn't enough, but -mlong-calls is needed. In that particular instance -mlong-calls is needed, but in the general case it appears not to be, judging from the numerous cases where only -ffunction-sections (and not -mlong-calls) is in use already in the archive. For example, #160538. My wishlist request still stands. waiting for feedback form the HPPA porters. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c5c2429.2040...@debian.org
DSO linking changes for wheezy
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 to disable one of these changes on some port. Thanks, Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ccacf9d.9080...@debian.org
Re: DSO linking changes for wheezy
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 --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 to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. This change is one I can agree with on technical grounds, though it will cause a great deal of pain in the short term. Have we got any estimates on exactly how much breakage will result before the change gets made? see http://wiki.debian.org/ToolChain/DSOLinking#Furtherinformation referenced in the first email of this thread. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce2c7c5.5040...@debian.org
GCC-4.5 as the default for (at least some) architectures
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 build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask which architectures should do the switch together with the four architectures mentioned above, and which not, and which ones should be better delayed, or dropped. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.5;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6d9e89.8080...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
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 for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask which architectures should do the switch together with the four architectures mentioned above, and which not, and which ones should be better delayed, or dropped. Could you add armhf to the list? keeping armhf to build from the linaro branch? Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e5293.8060...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
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 dumping all the armv4t systems that are using Debian armel. I didn't propose changing the minimum required processor for armel. I said that 4.5 looks ok, although I can only say that for another processor default (armv7-a). Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e787c.9090...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
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 distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? 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 go into unstable. 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. GCC 4.6 apparently will be used for the next Fedora and OpenSuse releases, and a test rebuild of Ubuntu natty doesn't look too bad (mostly adding new easily fixable C++ build failures). A test rebuild of the unstable archive is still outstanding, but these build failures will have to be fixed anyway. From my point of view it's important to expose GCC 4.6 early in the release cycle to fix issues like #617628 (which are issues in the packages itself) now. With GCC 4.6 comes one soname change, bumping the libobjc version from 2 to 3, which is not easily detachable from the GCC version change. However this change only affects GNUstep, which can be dealt with NMU's, or migration to a new GNUstep version. It's unlikely that GCC 4.5 will be released with wheezy, as the Debian Ada and D maintainers are already working on GCC 4.6 support. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6dea5.5010...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
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? yes, forgot about that. with GCC 4.6, armhf is built again from the 4.6 fsf branch, and lets us drop the GCC 4.5 Linaro variant. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6eb11.2080...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
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 and powerpc. If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? I don't know, and I will not invest time to check. If you did check, and if you are confident to fix issues on these architectures, then please tell here. At least for other ports this seems to be possible (s390: Bastian Blank, kfreebsd-*: Aurelian, Petr). I assume you want to release with at least 4.6 on all arches as the default, so I see no point in waiting with switching if there are no known issues. I will not work on toolchain issues specific to these architectures for the wheezy release, so if nobody steps forward, then at least I will not change the default for these architectures. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db73b0c.4000...@debian.org
please update patches / investigate build failures for gcc-4.7 snapshot builds
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. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eee7d60.9000...@debian.org
targeting GCC 4.7.0 as the wheezy default for some architectures
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 issues (help is welcome) in April, and then decide at the of April to change the default for some architectures; input from port maintainers is welcome if and when to change the default for any other archs. The current rebuild was done on amd64 only, any other (maybe partial) rebuild test on other architectures is welcome. The Java and Go frontends already default to 4.7, the D frontend may be updated for 4.7 in time (currently unused, as all D packages are built using gdc-v1). As I understand Ludovic, the Ada frontend will stay with 4.6. GCC-4.4 will stay in wheezy (D v1 frontend, somehow broken gcj-4.6 on release architectures like sparc). GCC-4.5 should be removed before the freeze. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian-...@lists.debian.org [2] http://gcc.gnu.org/gcc-4.7/porting_to.html -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7bfdac.4040...@debian.org
GCC 4.7 is now the default for x86 architectures
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 remaining quarter isn't blocking any other 4.7 build failures. Many thanks to the patch submitters and NMUers, including Cyril Brulebois, Gregor Herrmann, Paul Tagliamonte for the fixes. This will add one more transition for x86 (libobjc3 - libobjc4), which needs starting with uploads of some GNUstep base packages. The D v2 frontend is likely to be updated to 4.7 before the freeze (no build dependencies). Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa7ffd8.9010...@debian.org
Re: GCC 4.7 is now the default for x86 architectures
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. If a port is not a release architectures (and port maintainers don't plan to make it a release architecture), people can change the default at any time from my point of view. As for gcc-4.7 in general: a friend (authoring an ObjC framework _and_ runtime) told me that it dropped support for an old method of doing things while not fulfilling the promise to get the new method of doing it (don’t exactly remember what it was, /msg js on freenode for details) fixed, with the effect that gobjc-4.7 is virtually useless/broken. This is hearsay, but ask him for details, and check them against reality. I didn't rely on hearsay, but did ask the GNUstep maintainers for feedback. Please join the Debian GNUstep package maintainers ML if you want to add something, or review the past discussion. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa80a89.8070...@debian.org
Re: Bug#704020: gcc-4.8: FTBFS on hppa
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 don't see much sense anymore in having a current compiler without at least an unstable chroot. Back in Jan/Feb I did ask about the state of it, asked Aurelian to re-send open issues about ports.debian.org, but didn't get any reply. Thanks for applying the patch and trying to query Aurelian. therese seems to be a misunderstanding. Please look for an email to you sent on 2013-02-06, subject: [aurel...@aurel32.net: Re: hppa unstable buildd] referring to open questions mentioned in https://lists.debian.org/debian-hppa/2011/04/msg00026.html forwarding this email again to you and Helge this time. Regarding ports, I also never got any replies. Helge Deller and myself would still like to get a hppa buildd going. Had a couple of emails with Bdale on the subject. It appears that it may be possible to setup a wanna build server outside Debian although Helge favours using the existing Debian setup. Helge has setup a package upload system to parisc-linux.org. So, to access the packages that we have, one just has to add the following to /etc/apt/sources.list: deb ftp://ftp.de.debian.org/debian-ports unstable main deb ftp://ftp.parisc-linux.org/debian-ports/unstable unstable main There are a thousand or so packages there. Uploaded gcc-4.8 package set last night. Dave -- John David Anglindave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515448b6.3020...@debian.org
changing the java default to java7, and dropping java support for some architectures
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. There are a few cases, where Java7 is not yet an
alternative to Java6, so the transition should not be blocked on these missing
bits. However it should be clear that this is an interim solution, and OpenJDK 6
will be removed for jessie.
Currently java bindings/packages are built for all architectures, however some
architectures still use gcj as the (only available) Java implementation, and
some OpenJDK zero ports are non-functional at this point, and Debian porters
usually don't care about that. So the architectures to drop java support would
be
kfreebsd-any, hurd-i386, mips, mipsel, s390, ia64
- kfreebsd may gain java 7 support at some time, however this shouldn't
be relied on yet.
- hurd never had openjdk support, and afaik, nobody is working on that.
- openjdk support for mips and mipsel is currently broken, with several
requests for help on debian-mips left unanswered.
- I fixed openjdk on s390 for the release, however this architecture is
time comsuming to maintain, and again no answers on debian-s390 asking
for help.
- same experience on ia64, however the zero ports seems to work there.
The list of java archs is a bit changing, and to avoid hardcoding this list into
every source package, I propose to something similiar like done for the gcj
architectures (/usr/share/gcj/debian_defaults). Let the packages be still
architecture any, and decide whether to build arch dependent packages on a make
macro java_archs.
Build dependencies would still need hard-coding of the architecture list, so
another idea would be to keep the default-{jre,jdk} packages on all
architectures and only use them if the architecture is found in java_archs.
Matthias
--
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5187bca6.3010...@debian.org
Re: Current and upcoming toolchain changes for jessie
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/porting_to.html It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to remove 4.4, 4.6 and 4.7 from jessie. 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 any feedback from other port maintainers, so unless this does change and port maintainers get involved with toolchain maintenance, the architectures staying at 4.6 or 4.7 shouldn't be considered for a successful release (re-)qualification. 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. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b9c05f.8050...@debian.org
Re: Current and upcoming toolchain changes for jessie
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 stops FTBFSing. please send a patch. From me nothing against switching C/C++ to 4.8 for m68k at this point, but I’d like to hear at least Wouter’s opinion on that, and possibly Mikael since he’s not just doing work upstream on gcc but also using it (for ColdFire) heavily. same as well, please send a patch. For Ada, I’d like to see a successful build of gnat-4.8 (from src:gcc-4.8, if I understand the recent changes right) first; gnat-4.6 mostly works at the moment, but I’m not sure about the upstream situation wrt. patches from Mikael. try it and send a patch please. thanks for your cooperation, Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51baf88c.3080...@debian.org
Re: Current and upcoming toolchain changes for jessie
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 after the transition. The libc6.1 should (likely) depend on libunwind8 after that in order to guarantee that libunwind8 is installed. unless some ia64 porter steps up, it doesn't make sense to invest time into the ia64 port. So better drop ia64 now, and don't bother with libunwind on ia64. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51bf06cd.3070...@debian.org
Re: Bits from the Release Team (Jessie freeze info)
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 done well enough.) As an example I remember having received several complains from e.g. the GCC maintainers in regards to the state of gcc on various ports[1]. Here I would suspect a patch would be sufficient without needing to actually NMU gcc to get the fix in. There are also stuff like the port concerns from DSA that attention. Right. that's not enough. GCC has some primary and some secondary release architectures. Toolchain support for primary architectures in Debian should be waived, for the secondary and other architectures, Debian needs somebody who is maintaining the relationship between Debian and upstream. Surprisingly this is the case for many non-release Debian architectures like kfreebsd, the Hurd, alpha, hppa, m68k, but not for Debian release architectures like s390, sparc, ia64 and mips*. So we really need somebody to care about this, where the port is considered a secondary citizen or no citizen, or we should demote a port to the ports archive. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527c2170.8020...@debian.org
Re: Bug#731069: gcc-defaults: Please resume considering to change using unified version of gcc
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 status, please correct me if I'm wrong. - alpha, no feedback, CCing Michael Cree. - hppa, no feedback, CCing John David Anglin - ia64, no feedback, likely to be removed. - powerpc, found some feedback from the porters, but unrelated to toolchain issues, see https://lists.debian.org/debian-powerpc/2013/11/msg00050.html - powerpcspe, no feedback, CCing Roland Stigge. - ppc64, no feedback - s390x, pending upload - sparc, no feedback - sh4, no feedback, doesn't build, CCing Nobuhiro Iwamatsu Am 01.12.2013 16:45, schrieb Hiroyuki Yamamoto: Source: gcc-defaults Version: 1.123 Severity: wishlist Tags: patch Please resume considering to change using unified version of gcc, because FTBFS of many packages occur by e.g. c++11 on ports which stayed using gcc-4.6 and g++-4.6, ia64, powerpc, s390x, sparc, alpha, powerpcspe, ppc64, sh4. And using unified version of gcc must bring happiness to many package maintainers. On the other hand, I understand that this changing depends on the correspondence status of gcc porting, so I leave decision to you. This is a decision for the porters. If there are no active porters, there shouldn't be a port. Unfortunately, building gcc-4.8 source package on sh4 has not succeeded yet, so here is a patch which changes gcc-4.8 using on ports except sh4. Regards, -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529c7999.2040...@debian.org
Re: Bug#731069: gcc-defaults: Please resume considering to change using unified version of gcc
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 Debian. There is no response yet. I did check http://gcc.gnu.org/gcc-4.9/criteria.html and apparently ppc64 is a primary release architecture, so I did make it the default for sid (and will make 4.9 the default for jessie once uploaded to unstable). Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529e7cc6.1030...@debian.org
gcc-4.9 uploaded to experimental
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++ b-d on armel/armhf Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cfd843.1010...@debian.org
Re: Roll call for porters of architectures in sid and testing
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-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52de6b8b.2060...@debian.org
Re: Bug#745116: src:gcc-4.8: DEB_CROSS_NO_BIARCH=yes ignored for DEB_TARGET_ARCH=hppa
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 as well. The attached patch flips the default of with_hppa64 for this particular case. 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 without a compiler to build the kernel. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5351e2c8.6010...@debian.org
preparing for GCC 4.9
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 the gfortran default change, including the change of the Fortran 90 module version change. The Debian archive was rebuilt twice on amd64, once in February, resulting in bug submissions for GCC and feedback for the porting guide [1], a second time in March to file issues for packages failing to build with GCC 4.9 [2]. Another test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other compiler regressions on these architectures. I would like to see some partial test rebuilds (like buildd or minimal chroot packages) for other architectures. Any possibility to setup such a test rebuild for some architectures by the porters? Afaics the results for the GCC testsuite look okish for every architecture. I'll work on fixing the build failures in [2], help is of course appreciated. Almost all build failures are analyzed and should be easy to fix (exceptions e.g. #746883). Patches for the ones not caused by the Debian packaging may be found in distributions already using GCC 4.9 as the default compiler (e.g. Fedora 21). If anything goes well, and a large amount of build failures are fixed, I plan to make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of May, beginning of June. Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, 4.8) will be filed. Matthias [1] http://gcc.gnu.org/gcc-4.9/porting_to.html [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ba1ce.9070...@debian.org
Re: preparing for GCC 4.9
sorry, can't help with this. setting up a pbuilder or sbuild, and start building packages from the base system? Matthias Am 13.05.2014 03:26, schrieb David Gosselin: I'm in the same boat as Patrick, except with a PowerMac G5. Please let us know how to begin. Thanks, Dave On May 12, 2014, at 16:02, Patrick Baggett baggett.patr...@gmail.com wrote: Hi Matthias et al, I'd like to try to do some of this using my sparc box and see how far I get. Is there a link that explains how to set up these steps? Others seem to 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, 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, 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 the gfortran default change, including the change of the Fortran 90 module version change. The Debian archive was rebuilt twice on amd64, once in February, resulting in bug submissions for GCC and feedback for the porting guide [1], a second time in March to file issues for packages failing to build with GCC 4.9 [2]. Another test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other compiler regressions on these architectures. I would like to see some partial test rebuilds (like buildd or minimal chroot packages) for other architectures. Any possibility to setup such a test rebuild for some architectures by the porters? Afaics the results for the GCC testsuite look okish for every architecture. I'll work on fixing the build failures in [2], help is of course appreciated. Almost all build failures are analyzed and should be easy to fix (exceptions e.g. #746883). Patches for the ones not caused by the Debian packaging may be found in distributions already using GCC 4.9 as the default compiler (e.g. Fedora 21). If anything goes well, and a large amount of build failures are fixed, I plan to make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of May, beginning of June. Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, 4.8) will be filed. Matthias [1] http://gcc.gnu.org/gcc-4.9/porting_to.html [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ba1ce.9070...@debian.org -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5371fb4e.9090...@debian.org
Changing the GCC defaults to 4.9 for the remaining architectures (sh4, x32, powerpcspe, m68k)
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? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53a17c26.6060...@debian.org
Re: The (uncalled for) toolchain maintainers roll call for stretch
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 >> by the release team. I'd like to document the status how I do understand it >> for >> some of the toolchains available in Debian. > >> Java/OpenJDK >> >> >> For the stretch release openjdk-8 will be fine as the default java >> implementation. For buster, gcj (to be removed in GCC 7) won't be available >> anymore, and we'll end up with architectures without a java implementation. >> At >> the same time I'd like to consider to stop providing OpenJDK zero builds, >> leaving powerpc and mips* without a java implementation as well (currently >> not >> building for openjdk-9). armhf (not armel) and s390x have Hotspot ports >> underway. > > Can you explain the reason why you consider stopping OpenJDK zero builds? the zero builds usually break on various architectures when the hotspot version is updated. So the zero ports require extra work and hinder migration of the packages to testing when they ftbfs. Afaiu the security team also doesn't care about these ports when they fail to build for security updates. > I'm asking, because on hppa we currently use gcj and we don't have any > OpenJDK port yet. > My hope was to fix at some point in future the old existing OpenJDK zero port > patches to get some newer > JDK even if it's slower. With your intention to stop zero builds, we probably > won't have any > JDK at all... I can't care for all ports which are not release architectures. Feel free to - send patches for the openjdk-8 package - look at the openjdk-9 build failures and send patches for the openjdk-9 package - Prepare to get these patches into openjdk-10, do regular builds of openjdk-10 when it becomes open for development, and continue to do so as long as you want to have it building. Matthias
preparing for binutils-2.31
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 difference if you wait with the introduction of a new binutils version early or later with the release. These tend to be only fixed as Debian porters report them. Matthias [1] https://sourceware.org/ml/binutils/2018-06/msg00158.html [2] https://sourceware.org/ml/binutils/2018-06/msg00170.html
GCC and binutils updates for buster
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 expect runtime incompatibilities anymore. There is one more transistion involved, bumping the libgfortran version. A pre-release version of binutils 2.31 is in testing now, and the final 2.31 release in unstable. These are the major versions for the upcoming buster release, still planning updates to a potential GCC 8.3.0 (estimated Jan 2019) release and binutils 2.31.1 release, or doing equivalent updates from the release branches. There are still a bunch of build failures triggered by GCC 8 [1], so fixing these should get some priority now. See [2] for changes in GCC 8, and the porting guide [3]. I'll be at DebCamp for the second half of the week, and at DebConf, so if there is interest for bug squashing sessions, feel free to grab me, and we can schedule such sessions on a short notice. GCC 5 and GCC 6 are going away, and I am planning the same with GCC 7 as soon as there are upstream kernel and glibc releases which are released after the GCC 8.1.0 release from April. The Debian release team lists toolchain support for our release architectures, and according to [4], the amd64, i386, armel, armhf, arm64 architectures are supported as primary architectures, and s390x is supported as a secondary architectures. Some notes on other candidates for release architectures: - armel: The armv4t default isn't used very much anymore, and we had issues in the past. - armhf: While arm-linux-gnueabihf is not explicitly listed as a primary architecture, I'm told that the arm-linux-armeabi triplet covers the hard float variants as well. - ppc64el: Not documented as primary architecture, but according to the backend maintainers the powerpc64-linux-gnu triplet includes the le variant. - mips*: There is no support for any mips-linux target either as a primary or secondary release architecture (only bare metal), which matches the experience with mips specific issues for the past Debian releases. I understand that port maintainers want to have their port included as a release architecture, however it becomes a burden if neither the upstream nor the Debian port maintainers can keep up with the general upstream development. Maybe we need something in between the alternatives of being a release arch or not, having the benefit of packages in testing/stable, but not being supported in a release. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-8;users=debian-...@lists.debian.org [2] https://gcc.gnu.org/gcc-8/changes.html [3] https://gcc.gnu.org/gcc-8/porting_to.html [4] https://gcc.gnu.org/gcc-8/criteria.html signature.asc Description: OpenPGP digital signature
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
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 sponsors for >>hardware. >>(Raised by DSA; carried over from stretch) >> >> * Concern for armel and armhf: only secondary upstream support in GCC >>(Raised by the GCC maintainer; carried over from stretch) I don't think anybody objected about the status for armhf. I didn't follow armel issues too closely. >> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >>in GCC >>(Raised by the GCC maintainer; carried over from stretch) >> > > This is a misunderstanding as MIPS company had some unrest in recent half > year. > Currently we are stable now, and the shape of gcc upstream is also good. This is an optimistic view. While currently not having any RC issues, we still see mips* specific issues popping up more often than on other release architectures. According to https://gcc.gnu.org/gcc-8/criteria.html there is no mips*-linux* target listed as either primary or secondary platform. As far as I understand the mips porters argue that this is covered by mipsisa64-elf, a bare metal target. I don't agree with this view, because - testing is missing on mips*-linux-* targets. If you look at the gcc-testresults ML, you see only test reports submitted for the Debian GCC packages, nothing else. - A bare metal target is usually only built/used for C and C++. I doubt that other frontends are tested. - Configurations like libgcjit are not tested/used upstream, and not addressed. See #798710. The Debian bug tracking for the MIPS port could be better, I usually need some pings to the MIPS porters to get things forwarded or addressed. To me it looks sometimes that Debian is used for testing by upstream, and for that the mips architectures don't need to be release architectures. Matthias
gcc-8 and gcc-9 builds using pgo and lto optimization
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 worth the extra build time, please file an issue for the package to disable those optimizations. Matthias
Same procedure as every year: GCC defaults change (GCC 9)
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 gnat defaults change will be handled separately by the Debian Ada maintainers. The fortran module changes look ok according to Alastair McKinstry. The gcc-9 package still ftbfs on kfreebsd-*. We still have local patches for at least the various mips, kfreebsd and hurd targets. Please forward these upstream and make sure that these are applied upstream. powerpcspe support is removed upstream. I will keep pointing the default to GCC 8 for this target. Matthias
GCC and binutils plans for bullseye
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 making the GCC switch. The GCC 10 switch involves some minor library transitions for D, gccgo, M2, which should be no-brainers. The gnat transition will be handled separately by the debian Ada maintainers. binutils should be pretty stable until the bullseye release, not planning an update to 2.36. GCC 10 should be updated to 10.3, or close to 10.3 (the release date is not yet known, could be Feb 2021). I'd like to get rid off GCC 8 and GCC 9 for the bullseye release. Matthias
Re: Porter roll call for Debian Bullseye
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 packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in testing ... > - triage arch-specific bugs > - fix arch-related bugs any help with #972269 ?
Bug#999845: debugedit test failures on hppa
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: https://buildd.debian.org/status/fetch.php?pkg=debugedit=hppa=1%3A5.0-1=1637090819=0 /bin/bash ./testsuite ## - ## ## debugedit 5.0 test suite. ## ## - ## debugedit 1: debugedit help ok 2: debugedit usage ok 3: debugedit executableok 4: debugedit .debug_str objects DWARF4 FAILED (debugedit.at:107) 5: debugedit .debug_str/line_str objects DWARF5FAILED (debugedit.at:140) 6: debugedit .debug_str partial DWARF4 FAILED (debugedit.at:174) 7: debugedit .debug_str/line_str partial DWARF5FAILED (debugedit.at:206) 8: debugedit .debug_str exe DWARF4 ok 9: debugedit .debug_str/line_str exe DWARF5ok 10: debugedit .debug_info objects FAILED (debugedit.at:304) 11: debugedit .debug_info partial FAILED (debugedit.at:329) 12: debugedit .debug_info exe ok 13: debugedit .debug_types objects FAILED (debugedit.at:383) 14: debugedit .debug_types partial FAILED (debugedit.at:416) 15: debugedit .debug_types exe ok 16: debugedit .debug_line objects DWARF4FAILED (debugedit.at:473) 17: debugedit .debug_line objects DWARF5skipped (debugedit.at:491) 18: debugedit .debug_line partial DWARF4FAILED (debugedit.at:524) 19: debugedit .debug_line partial DWARF5skipped (debugedit.at:540) 20: debugedit .debug_line exe DWARF4ok 21: debugedit .debug_line exe DWARF5skipped (debugedit.at:587) 22: debugedit .debug_macro objects FAILED (debugedit.at:620) 23: debugedit .debug_macro partial FAILED (debugedit.at:645) 24: debugedit .debug_macro exe ok 25: debugedit --list-file DWARF4ok 26: debugedit --list-file DWARF5ok ## - ## ## Test results. ## ## - ## ERROR: 23 tests were run, 12 failed unexpectedly. 3 tests were skipped.
Bug#1014098: gcc-12 ftbfs 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 /hppa-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/hppa-linux-gnu/libstdc++-v3/libs upc++/.libs -B/usr/hppa-linux-gnu/bin/ -B/usr/hppa-linux-gnu/lib/ -isystem /usr/hppa-linux-gnu/i nclude -isystem /usr/hppa-linux-gnu/sys-include -isystem /<>/build/sys-include -fno -checking -I/<>/src/libstdc++-v3/../libgcc -I/<>/build/hppa-linux-gnu/ libstdc++-v3/include/hppa-linux-gnu -I/<>/build/hppa-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-temp lates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunct ion-sections -fdata-sections -frandom-seed=ostream-inst.lo -g -O2 -D_GNU_SOURCE -c ../../../../. ./src/libstdc++-v3/src/c++11/ostream-inst.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o ostream-inst.o /tmp/ccegw8OX.s: Assembler messages: /tmp/ccegw8OX.s:61950: Error: junk at end of line, first unrecognized character is `:' /tmp/ccegw8OX.s:225758: Error: leb128 operand is an undefined symbol: .LVU12413 make[8]: *** [Makefile:656: cxx11-wlocale-inst.lo] Error 1 make[8]: *** Waiting for unfinished jobs make[8]: Leaving directory '/<>/build/hppa-linux-gnu/libstdc++-v3/src/c++11' make[7]: *** [Makefile:783: all-recursive] Error 1
