icc with gcc 4.0.1 fails
On my 'unstable' box, gcc recently got upgraded to 23:35:48 ~/C$ gcc --version gcc (GCC) 4.0.1 (Debian 4.0.1-1) but now my existing Intel C compile installation falls over: 23:43:58 ~/C$ icc test.c Command-line error: invalid GNU version number: 401 compilation aborted for test.c (code 4) Has anybody else seen this or, more usefully, know the fix? Thanks, -- Michael Bane Atmospheric Physics Group University of Manchester -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mesa: [regression] with Mesa 18.2.5-2 the charackter model in Tomb Raider is no longer rendered.
Control: reassign -1 src:mesa 18.2.5-2 Control: severity -1 important Control: clone -1 -2 Control: reassign -2 gcc-8 8.2.0-9 Control: retitle -2 gcc-8 miscompiles mesa Control: forwarded -2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 Control: tags -2 + patch Control: affects -2 src:mesa On Thu, 22 Nov 2018 02:32:35 +0100 GSR wrote:> Package: mesa > Version: 18.2.5-2 > Followup-For: Bug #914267 > > That looks like missing shaders. I hit a similar thing with mpv (just > blue window, sound but no video) after upgrading 18.2.5-1 => 18.2.5-2, > luckly showing some output that later helped with searches. > > ---8<--- > [vo/gpu/opengl] fragment shader compile log (status=0): > [vo/gpu/opengl] 0:36(27): error: invalid input layout qualifier used > [vo/gpu/opengl] > [vo/gpu/opengl] shader link log (status=0): error: linking with uncompiled/unspecialized shader > --->8--- > > Bug 914303 could be the same too, garbled or single color output could > mean shaders not working because they failed to compile. Looking up > the error text, I found the culprit could be gcc, creating faulty > mesa binaries. https://bugs.freedesktop.org/show_bug.cgi?id=108646 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 I ran into a similar issue. I use vmware and hosts using 3D acceleration no longer start successfully. On stdout I get the error message NOT_IMPLEMENTED bora/mks/renderers/gl/GLShader.c:1887 I can confirm the findings of GSR that this appears to be a gcc-8 regression. Rebuilding src:mesa with gcc-7 fixed those issues for me. Might be a good idea to (temporarily) switch to gcc-7 depending on how long it takes until this fix is applied in gcc-8. The attached patch worked for me. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? diff -u mesa-18.2.5/debian/changelog mesa-18.2.5/debian/changelog --- mesa-18.2.5/debian/changelog +++ mesa-18.2.5/debian/changelog @@ -1,3 +1,11 @@ +mesa (18.2.5-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Force compilation against gcc-7, gcc-8 miscompiles mesa +See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 + + -- Michael Biebl Thu, 22 Nov 2018 03:32:38 +0100 + mesa (18.2.5-2) unstable; urgency=medium * Move KHR/khrplatform.h from libegl1-mesa-dev to mesa-common-dev diff -u mesa-18.2.5/debian/control mesa-18.2.5/debian/control --- mesa-18.2.5/debian/control +++ mesa-18.2.5/debian/control @@ -6,6 +6,9 @@ Standards-Version: 4.1.4 Build-Depends: debhelper (>= 11), + gcc-7, + g++-7, + cpp-7, quilt (>= 0.63-8.2~), pkg-config, libdrm-dev (>= 2.4.92) [!hurd-any], diff -u mesa-18.2.5/debian/rules mesa-18.2.5/debian/rules --- mesa-18.2.5/debian/rules +++ mesa-18.2.5/debian/rules @@ -10,6 +10,9 @@ DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU) +export CC = gcc-7 +export CXX = g++-7 + ifeq (,$(filter $(DEB_HOST_ARCH), armhf sh3 sh4)) buildflags = \ $(shell DEB_CFLAGS_MAINT_APPEND=-Wall DEB_CXXFLAGS_MAINT_APPEND=-Wall dpkg-buildflags --export=configure) signature.asc Description: OpenPGP digital signature
Bug#914316: Fixed in gcc-8 8.2.0-10
On Sat, 24 Nov 2018 09:33:11 +0100 Sven Joachim wrote: > Source: gcc-8 > Version: 8.2.0-10 > > The miscompilation of mesa has been fixed in the latest gcc-8 upload, > please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 for > details. I recompiled mesa with 8.2.0-10 and I can confirm the fix. Andreas, thank you for the quick mesa update! Feel free to drop my workaround again in one of your next uploads. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#925624: [Debichem-devel] Bug#925624: Bug#925624: abinit: ftbfs with GCC-9
Hi, On Sat, Sep 07, 2019 at 10:50:34PM +0200, Michael Banck wrote: > > Program received signal SIGSEGV: Segmentation fault - invalid memory > > reference. > > > > Backtrace for this error: > > #0 0x7f063149eb40 in ??? > > #1 0x7f063149dd75 in ??? > > #2 0x7f063115893f in ??? > > #3 0x5612b98bb243 in forces_ > > at /<>/src/67_common/forces.F90:462 > > So at that line we have: > > | if (usefock==1 .and. associated(fock).and.fock%fock_common%optfor) then > > and if I step through that function with gdb, usefock is 0 (while fock > is pointing to 0x0). > > If I comment out the above if block (plus two more pretty much identical > ones in m_forstr.F90 and m_stress.F90) most of the tests run fine (I > guess the other ones really do need fock). > > I am a bit baffled why gfortran compiles this in such a way (at -g > without any -O as well) that we get a segfault here. I now tried with > FCFLAGS='-g -O2' and then the test suite runs fine, so reassigning to > gfortran-9 for now, do you have an idea what's going on? > > (I filed this one upstream as well: > https://github.com/abinit/abinit/issues/25) So it appears that fock%fock_common%optstr cannot be guaranteed not to be evaluated after associated(fock) is false as the Fortran language apparently does not define short-circuit beahviour, see https://www.scivision.dev/fortran-short-circuit-logic/ That explains why it works fine at -O2 (and would as well at -O1 in gfortran), but crashed in -O0. I wonder why it built fine at -O0 in stable though, it might be that the gfortran behaviour has been changed recently. I guess the fix would be to have two ifs here, like: | if (usefock==1 .and. associated(fock)) then | if (fock%fock_common%optfor) then | grtn(:,:)=grtn(:,:)+fock%fock_common%forces(:,:) | end if | end if I've uploaded abinit with FCFLAGS=-O2 now, should we close this bug and leave it to the abinit maintainers to fix it properly, or do you want to reassign it back? Thanks to juliank for pointing me to the potential short-circuit logic issue. Michael
Bug#973545: gcc-10: 10.2.0-15 to 10.2.0-16 900MB larger?
Package: gcc-10 Version: 10.2.0-16 Severity: wishlist When upgrading from 10.2.0-15 to 10.2.0-16 aptitude reports that gcc-10 is 282MB larger, g++-10 is 312MB larger, and cpp-10 is 283MB larger. In -15 /usr/lib/gcc/x86_64-linux-gnu/10/lto1 is 26M and in -16 /usr/lib/gcc/x86_64-linux-gnu/10/lto1 is 285M. I assume this is because of the "don't strip the executables" changelog entry. If that's the case you do another release like this, please be explicit that this will cause a massive increase in disk utilization, since that is potentially really significant growth in core component that isn't usually very large and people may wonder what happened to their disk space.
Bug#975219: [Debichem-devel] Bug#975219: elkcode: FTBFS: internal compiler error: in lookup_field_for_decl, at tree-nested.c:288
Hi Lucas, That looks like an ICE, shouldn't that be filed with gfortran? On Thu, Nov 19, 2020 at 10:52:05AM +0100, Lucas Nussbaum wrote: > > mpif90 `dpkg-buildflags --get FFLAGS` `dpkg-buildflags --get CPPFLAGS` > > -Wall -ffast-math -funroll-loops -fopenmp -fallow-argument-mismatch > > `dpkg-buildflags --get LDFLAGS` -c exxengy.f90 > > exxengy.f90:6:18: > > > > 6 | subroutine exxengy > > | ^ > > internal compiler error: in lookup_field_for_decl, at tree-nested.c:288 > > 0x71106d lookup_field_for_decl > > ../../src/gcc/tree-nested.c:288 > > 0x111523e convert_local_reference_stmt > > ../../src/gcc/tree-nested.c:2408 [...] > > Please submit a full bug report, > > with preprocessed source if appropriate. > > Please include the complete backtrace with any bug report. > > See for instructions. > > make[3]: *** [Makefile:194: exxengy.o] Error 1 Michael
Bug#972789: qemu: FTBFS on arm{el,hf}: /<>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible
On Wed, 28 Oct 2020 12:30:41 +0100 Sebastian Ramacher wrote: On 2020-10-24 07:38:39 +0300, Michael Tokarev wrote: ... > Hmm. So this looks like a gcc ICE bug. Here's the code in question: > ... > > | /<>/linux-user/m68k/signal.c:44:1: internal compiler error: ‘verify_type’ failed > > I'm not sure what I have to do with this, besides reassigning it to gcc. > > BTW, symbol TYPE_CANONICAL is not used/referenced by qemu sources. Indeed, that's a bug in gcc which was already reported upstream. Reassigning accordingly. I dunno what happened, either it was new gcc or new qemu, but this issue is gone - as of today's upload of qemu 5.2 it built successfully on both armhf and armel. Guess we can close this bugreport, what do you think? /mjt
Bug#985565: libdebuginfod1: libdebuginfod-common is missing
Package: libdebuginfod1 Version: 0.183-5 Severity: important Dear Maintainer, There is no architecture entry for all on buildd.debian.org and on packages on incoming.debian.org -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (710, 'unstable'), (670, 'testing'), (660, 'experimental'), (600, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libdebuginfod1 depends on: ii libc6 2.31-9 ii libcurl3-gnutls 7.74.0-1.1 ii libdebuginfod-common 0.183-5 ii libdw10.183-5 ii libelf1 0.183-5 libdebuginfod1 recommends no packages. libdebuginfod1 suggests no packages. -- no debconf information
Bug#1036158: gcc-13: Please raise baseline for alpha to EV56
On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote: > After a long discussion on IRC and the mailing list, we have agreed to raise > the > baseline for the alpha architecture to EV56 to improve the generated code and > fix > a number of issues. The change is already being implemented in the glibc > packages > which switches to EV56 [1] since hwcaps are no longer available with glibc > 2.37 [2]. > > Could you raise the baseline for gcc on alpha to EV56? > > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56". Yes, please! I suggest the following in debian/rules2: ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH))) CONFARGS += --with-cpu=ev56 --with-tune=ev6 endif (the --with-tune only affects instruction scheduling and better tunes code for ev6 and more recent machines, but allows execution down to ev56.) I have tested this in the past with a rebuild of most packages that are in the base essential chroot in the past and it works well. Regards, Michael.
Bug#1036158: gcc-13: Please raise baseline for alpha to EV56
On Wed, May 17, 2023 at 11:27:43AM +0200, John Paul Adrian Glaubitz wrote: > Hi Michael! > > On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote: > > On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote: > > > After a long discussion on IRC and the mailing list, we have agreed to > > > raise the > > > baseline for the alpha architecture to EV56 to improve the generated code > > > and fix > > > a number of issues. The change is already being implemented in the glibc > > > packages > > > which switches to EV56 [1] since hwcaps are no longer available with > > > glibc 2.37 [2]. > > > > > > Could you raise the baseline for gcc on alpha to EV56? > > > > > > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56". > > > > Yes, please! > > > > I suggest the following in debian/rules2: > > > > ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH))) > > CONFARGS += --with-cpu=ev56 --with-tune=ev6 > > endif > > > > (the --with-tune only affects instruction scheduling and better tunes > > code for ev6 and more recent machines, but allows execution down to > > ev56.) I have tested this in the past with a rebuild of most packages > > that are in the base essential chroot in the past and it works well. > > Doesn't that come with a speed penalty for EV56 machines? I'm asking because > EV56 is > currently the baseline for QEMU when emulating Alpha. I was under the impression that qemu was ev6/ev67 being machine type clipper which emulates an ES40. Am I mistaken? With regards instruction scheduling EV56 is in-order two-instructions [1] executed per cycle. EV6 and EV67 are out-of-order [2] four-instructions executed per cycle. Hence, for ev6/ev67 it can be advantageous to bring forward instructions that are data (operand) ready and delaying by four cpu-instructions those that depend on a result of a previous instruction instead of placing them immediately after the previous instruction to guarantee they don't waste an instruction slot in the same cpu cycle. [3] The deleterious impact on ev56 of doing this will be very small to utterly negligible. It is not worth worrying about. Regards, Michael. [1] Here I am talking about most integer register/register operate instructions. Memory, integer multiply and floating-point instructions have longer latencies. [2] Note that out-of-order does not mean the cpu can bring forward data ready instructions that have not yet been seen in the instruction pipeline. That is why we ask the compiler to place them earlier. [3] Even more advantageous on ev6/ev67 is to loop unroll and evaluate two iterations of the loop in parallel, i.e., intertwine the two computational pathways. When I did tests some time ago with gcc (4.6 and earlier versions) the compiler did not do this well, whereas my manually optimised machine code was getting better than three instructions executed per cpu cyle on certain code.
Bug#1038134: g++-12: Conditional compilation error in optimized mode
Package: g++-12
Version: 12.2.0-14
Severity: normal
X-Debbugs-Cc: iv...@isle.spb.ru
Dear Maintainer,
When I compile c++ code which has an error (method invoked on
null class pointer) the following problem occurs: the actual
call does not crash, since 'this' pointer is not really used
in called method, but conditional below works incorrectly.
Here's the simplified code in question:
else {
np = getstr(cp);
if (!::strcasecmp(np, "info"))
current = channel->get_class(ErrorCode::Info);
else if (!::strcasecmp(np, "internal"))
current = channel->get_class(ErrorCode::Internal);
. . . . . .
else {
Log::Error("%s:%d: unrecognized error class [%s]", _fname, _lineno,
np);
current = 0;
continue;
}
}
if (!channel || !current)
continue;
np = getstr(cp);
channel can be 0 after first 'else', but get_class() does not crash,
since it just returns a computed pointer to array item inside the
object, so that current is set to some invalid value like 0x120.
It proceeds to the 'if (!channel || !current)' conditional and
with given values (channel == 0, current == 0x120) continue should
be executed. Instead the control falls through to the next line.
This error occurs only when the code is compiled with -O2 or -O3.
When -O0 is used, the conditional works properly. The error is
not observed when compiled with g++-11.
The error also dissappears when I fix my error (replace first
'else {' by 'else if (channel) {').
If this information is of any interest I can send combined
c++/assembly listings for cases with and without optimization.
Best regards,
-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-23-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages g++-12 depends on:
ii gcc-1212.2.0-14
ii gcc-12-base 12.2.0-14
ii libc6 2.36-9
ii libgmp10 2:6.2.1+dfsg1-1.1
ii libisl23 0.25-1
ii libmpc3 1.3.1-1
ii libmpfr6 4.2.0-1
ii libstdc++-12-dev 12.2.0-14
ii libzstd1 1.5.4+dfsg2-5
ii zlib1g1:1.2.13.dfsg-1
g++-12 recommends no packages.
Versions of packages g++-12 suggests:
pn g++-12-multilib
pn gcc-12-doc
-- no debconf information
Bug#1065276: please build loong64 packages
Source: gcc-14-cross-ports Version: 4 Severity: wishlist X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org Please consider building loong64 cross-compiler too, once this architecture has become one of debian ports. In particular, this is needed to build qemu (only a tiny part so far, vdso.so helper binary for qemu-user, but it is aready nearly impossible to do without a cross-compiler). Thanks, /mjt
Bug#894014: cpp-8: /usr/lib/gcc/x86_64-linux-gnu/8/cc1 is not stripped
Package: cpp-8 Version: 8-20180321-1 Severity: minor Dear Maintainer, /usr/lib/gcc/x86_64-linux-gnu/8/cc1 is not stripped and therefore quite large (171M). The same is true for /usr/lib/gcc/x86_64-linux-gnu/8/lto1. For other gcc versions, these files are stripped, so I guess they should also be stripped for gcc-8. -- System Information: Debian Release: buster/sid APT prefers experimental APT policy: (900, 'experimental'), (900, 'unstable'), (600, 'testing'), (550, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cpp-8 depends on: ii gcc-8-base 8-20180321-1 ii libc6 2.27-2 ii libgmp102:6.1.2+dfsg-3 ii libisl190.19-1 ii libmpc3 1.1.0-1 ii libmpfr64.0.1-1 ii zlib1g 1:1.2.8.dfsg-5 cpp-8 recommends no packages. Versions of packages cpp-8 suggests: pn gcc-8-locales -- no debconf information
Bug#899219: gcc-8: __builtin_ms_va_list missing on arm64
package: src:gcc-8 severity: normal version: 8.1.0-3 Wine now relies on this [0], but it seems to be missing in gcc on arm64. It is supported in newer versions of clang on arm64. Best wishes, Mike [0]https://buildd.debian.org/status/fetch.php?pkg=wine-development&arch=arm64&ver=3.8-1&stamp=1526746237&raw=0
Bug#902293: gcc-6: internal compiler error in convert_move on arm
package: src:gcc-6 version: 6.4.0-18 severity: grave control: affects -1 src:chromium-browser forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86166 This was marked as a duplicate upstream and closed, but it seems like it should be considered a separate issue. The latest chromium upload now fails because of this [0] (using gcc 6.4.0-18, which includes the fix for #901290). Best wishes, Mike [0]https://buildd.debian.org/status/fetch.php?pkg=chromium-browser&arch=arm64&ver=68.0.3440.17-1&stamp=1529836062&raw=0
Bug#1006425: wrong dependency on gcc-11-s390x-linux-gnu after gcc-12 switch: it is gcc-12-s390x-linux-gnu now
Package: gcc-s390x-linux-gnu Version: 4:11.2.0-2 Severity: normal Current package have: Depends: cpp-s390x-linux-gnu (= 4:11.2.0-2), gcc-11-s390x-linux-gnu (>= 11.2.0-1~) It looks like after switch to gcc-12, it should be gcc-12-s390x-linux-gnu instead. Currently in unstable, gcc-s390x-linux-gnu is uninstallable since gcc-11-s390x-linux-gnu depends on libgcc-11-something which does not exist. But I'm not sure about it really, - which package should be fixed. Thanks, /mjt
Bug#968670: dwz: Fails with "Unknown DWARF DW_OP_1" (more info needed)
On Sat, 6 Feb 2021 08:54:57 +0100 Dennis Filder wrote: Control: tag -1 - patch + moreinfo After looking into this some more, I don't think this is necessarily a bug in dwz, but it could also be either someone using rogue DW_OP_* definitions with values 0x00 and 0x01 or a buggy compiler/assembler backend emitting junk. While applying the patch probably won't hurt, it will most probably not help either. This prob now started appearing on ppc64el and s390x buildds on regular bullseye builds, f.e. https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=s390x&ver=1%3A7.0%2Bdfsg-2%7Ebpo11%2B1&stamp=1651985111&raw=0 https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=ppc64el&ver=1%3A7.0%2Bdfsg-2%7Ebpo11%2B1&stamp=1651980296&raw=0 dh_dwz -a -a dwz: debian/qemu-system-misc/usr/bin/qemu-system-alpha: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-hppa: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-riscv32: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-riscv64: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-s390x: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-sh4: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-sh4eb: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-xtensa: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-xtensaeb: Unknown DWARF DW_OP_0 dh_dwz: error: dwz -mdebian/qemu-system-misc/usr/lib/debug/.dwz/powerpc64le-linux-gnu/qemu-system-misc.debug -M/usr/lib/debug/.dwz/powerpc64le-linux-gnu/qemu-system-misc.debug -- debian/qemu-system-misc/usr/bin/qemu-system-alpha debian/qemu-system-misc/usr/bin/qemu-system-avr debian/qemu-system-misc/usr/bin/qemu-system-cris debian/qemu-system-misc/usr/bin/qemu-system-hppa debian/qemu-system-misc/usr/bin/qemu-system-m68k debian/qemu-system-misc/usr/bin/qemu-system-microblaze debian/qemu-system-misc/usr/bin/qemu-system-microblazeel debian/qemu-system-misc/usr/bin/qemu-system-nios2 debian/qemu-system-misc/usr/bin/qemu-system-or1k debian/qemu-system-misc/usr/bin/qemu-system-riscv32 debian/qemu-system-misc/usr/bin/qemu-system-riscv64 debian/qemu-system-misc/usr/bin/qemu-system-rx debian/qemu-system-misc/usr/bin/qemu-system-s390x debian/qemu-system-misc/usr/bin/qemu-system-sh4 debian/qemu-system-misc/usr/bin/qemu-system-sh4eb debian/qemu-system-misc/usr/bin/qemu-system-tricore debian/qemu-system-misc/usr/bin/qemu-system-xtensa debian/qemu-system-misc/usr/bin/qemu-system-xtensaeb returned exit code 1 make[1]: *** [debian/rules:636: install-arch] Error 25 (it is DW_OP_0 not DW_OP_1, but since the above note suggests both should not be seen "in wild", maybe these are related). Is dwz or compiler broken on bullseye? Thanks, /mjt
Bug#968670: dwz: Fails with "Unknown DWARF DW_OP_1" (more info needed)
It is the same on arm64 too, eg: https://buildd.debian.org/status/package.php?p=qemu&suite=bullseye-backports /mjt
Bug#1019011: -mbuild-constants is broken in gcc-12.2
Package: gcc-12-alpha-linux-gnu
Version: 12.2.0-1cross3
Severity: normal
Starting this version of gcc, -mbuild-constants option causes it to produce
an ICE. Example is below. This is an old code, always worked before, in
particular with gcc-11.
Removing -mbuild-constants fixes the ICE. But this is a bios/firmware code,
and this option is used for purpose. Tho I don't know how important it
really is.
I tried to submit this bug upstream, but failed at the bugzilla registration
step.
// Target: alpha-linux-gnu
// Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libssp
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --enable-multiarch --disable-werror
--with-long-double-128 --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=alpha-linux-gnu
--program-prefix=alpha-linux-gnu- --includedir=/usr/alpha-linux-gnu/include
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 12.2.0 (Debian 12.2.0-1)
//
// during RTL pass: expand
// [01m[Kconsole.c:[m[K In function ‘[01m[Kdo_console[m[K’:
// [01m[Kconsole.c:130:12:[m[K [01;31m[Kinternal compiler error: [m[Kin
emit_move_insn, at expr.cc:4010
// 130 | [01;31m[Kvga[0] = 'H' + attr[m[K;
// | [01;31m[K~~~^~~~[m[K
// 0x13117e6 internal_error(char const*, ...)
// ???:0
// 0x5a6f34 fancy_abort(char const*, int, char const*)
// ???:0
// 0xdca64a alpha_split_const_mov(machine_mode, rtx_def**)
// ???:0
// 0xdca7b1 alpha_expand_mov(machine_mode, rtx_def**)
// ???:0
// 0x10d7ea9 gen_movv4hi(rtx_def*, rtx_def*)
// ???:0
// 0x7dcd97 emit_move_insn_1(rtx_def*, rtx_def*)
// ???:0
// 0x7dd15f emit_move_insn(rtx_def*, rtx_def*)
// ???:0
// 0xdccec6 alpha_expand_movmisalign(machine_mode, rtx_def**)
// ???:0
// 0x10d80e6 gen_movmisalignv4hi(rtx_def*, rtx_def*)
// ???:0
// 0xa053f8 expand_insn(insn_code, unsigned int, expand_operand*)
// ???:0
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See for instructions.
// /usr/lib/gcc-cross/alpha-linux-gnu/12/cc1 -quiet -imultilib . -imultiarch
alpha-linux-gnu -D SYSTEM_H="sys-clipper.h" console.c -quiet -dumpbase
console.c -dumpbase-ext .c -msmall-text -msmall-data -mno-fp-regs
-mbuild-constants -mcpu=ev67 -g1 -O2 -Wall -fdiagnostics-color=always
-fvisibility=hidden -fno-strict-aliasing -freport-bug -o - -frandom-seed=0
-fdump-noaddr
# 0 "console.c"
# 1 "/build/pkg/qemu-7.1+dfsg/b/qemu-palcode//"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "console.c"
# 21 "console.c"
# 1 "protos.h" 1
# 27 "protos.h"
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long uint64_t;
typedef unsigned long size_t;
typedef __builtin_va_list va_list;
extern void *memset(void *, int, size_t);
extern void *memcpy(void *, const void *, size_t);
extern size_t strlen(const char *);
static inline void wrent(void *cb, unsigned long which)
{
register void *a0 __asm__("$16") = cb;
register unsigned long a1 __asm__("$17") = which;
asm volatile ("call_pal 0x34"
: "+r"(a0), "+r"(a1)
: : "$1", "$22", "$23", "$24", "$25");
}
static inline unsigned long swpipl(unsigned long newipl)
{
register unsigned long v0 __asm__("$0");
register unsigned long a0 __asm__("$16") = newipl;
asm volatile ("call_pal 0x35"
: "=r"(v0), "+r"(a0)
: : "$1", "$22", "$23", "$24", "$25");
return v0;
}
static inline unsigned long rdps(void)
{
register unsigned long v0 __asm__("$0");
asm volatile ("call_pal 0x36"
: "=r"(v0) : : "$1", "$22", "$23", "$24", "$25");
return v0;
}
static inline void wrkgp(void)
{
asm volatile ("mov $29, $16\n\tcall_pal 0x37"
: : : "$16", "$1", "$22", "$23", "$24", "$25");
}
static inline unsigned long wtint(unsigned long skip)
{
register unsigned long v0 __asm__("$0");
register unsigned long a0 __asm__("$16") = skip;
asm volatile ("call_pal 0x3e"
: "=r"(v0), "+r"(a0)
: : "$1", "$22", "$23", "$24", "$25");
return v0;
}
static inline unsigned long ldq_p(unsigned long addr)
{
register unsigned long v0 __asm__("$0");
register unsigned long a0 __asm__("$16") = 1;
register unsigned long a1 __asm__("$17") = addr;
asm volatile ("call_pal 9"
: "=r"(v0), "+r"(a0), "+r"(a1) :
: "$18", "$19",
Bug#145447: gij: Here's a fix
Package: gij Version: 2:3.0.4-5 Followup-For: Bug #145447 This postinst should work: #! /bin/sh -e update-alternatives --quiet --install /usr/bin/java java /usr/bin/gij-wrapper-3.0 30 --slave /usr/share/man/man1/java.1.gz java.1.gz /usr/share/man/man1/gij-wrapper-3.0.1.gz || true # dh_doclink if [ "$1" = "configure" ]; then if [ -d /usr/doc -a ! -e /usr/doc/gij-3.0 -a -d /usr/share/doc/gij-3.0 ]; then ln -sf ../share/doc/gij-3.0 /usr/doc/gij-3.0 fi fi exit -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux micha 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: LANG=de_DE, LC_CTYPE=de_DE Versions of packages gij depends on: ii cpp 2:2.95.4-14 The GNU C preprocessor. ii gij-3.0 1:3.0.4-8 The GNU Java bytecode interpreter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148662: gcj-3.1 used wrong libgcj
Package: gcj-3.1 Version: 1:3.1-2 Severity: normal I tried to use gcj-3.1 to compile an app I'm helping with development. Unfortunately an old libgcj2 from gcj-3.0 was installed. gcj-3.1 used this version of libgcj installed of the version of libgcj3, which was intalled too. IMO gcj-3.1 should replace gcj-3.0 and depend on libgcj3. libgcj3 should replace libgcj2. A second problem is that ant can only use "gcj" as executable name, not "gcj-3.1" IMO should provide a symlink from /usr/bin/gcj to /usr/bin/gcj-3.1 -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux asterix 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set) Versions of packages gcj-3.1 depends on: ii gcc-3.1 1:3.1-2The GNU C compiler. ii gcc-3.1-base 1:3.1-2The GNU Compiler Collection (base ii java-common 0.14 Base of all Java packages ii libc6 2.2.5-6GNU C Library: Shared libraries an ii libgcc1 1:3.1-2GCC support library. ii libgcj3 1:3.1-2Java runtime library for use with ii libgcj3-dev 1:3.1-2Java development headers and stati ii zlib1g1:1.1.4-1 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148676: libgcj3: File duplicate
Package: libgcj3 Version: 1:3.1-2 Severity: normal libgcj3 includes the file called: /usr/lib/security/classpath.security Unfortunately the package "classpath" includes the same file. Either libgcj3 shouldn't include this file or both packages should forbid the other. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux asterix 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set) Versions of packages libgcj3 depends on: ii libc6 2.2.5-6GNU C Library: Shared libraries an ii libgcc1 1:3.1-2GCC support library. ii zlib1g1:1.1.4-1 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148682: gij-3.1: /usr/bin/gij-wrapper-3.1 tries to execute wrong gij
Package: gij-3.1 Version: 1:3.1-2 Severity: normal gij-3.1 contains the file /usr/bin/gij-wrapper-3.1. This file tries to execute the file /usr/bin/gij-3.0 which is part of gij-3.0. It should execute /usr/bin/gij-3.1 -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux asterix 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set) Versions of packages gij-3.1 depends on: ii gcc-3.1-base 1:3.1-2The GNU Compiler Collection (base ii libc6 2.2.5-6GNU C Library: Shared libraries an ii libgcc1 1:3.1-2GCC support library. ii libgcj3 1:3.1-2Java runtime library for use with ii zlib1g1:1.1.4-1 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148686: gcj-3.1 should provide /etc/alternatives/javac
Package: gcj-3.1 Version: 1:3.1-2 Severity: normal gcj-3.1 should provide /etc/alternatives/javac -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux asterix 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set) Versions of packages gcj-3.1 depends on: ii gcc-3.1 1:3.1-2The GNU C compiler. ii gcc-3.1-base 1:3.1-2The GNU Compiler Collection (base ii java-common 0.14 Base of all Java packages ii libc6 2.2.5-6GNU C Library: Shared libraries an ii libgcc1 1:3.1-2GCC support library. ii libgcj3 1:3.1-2Java runtime library for use with ii libgcj3-dev 1:3.1-2Java development headers and stati ii zlib1g1:1.1.4-1 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148725: gij-3.1 should provide java-runtime2
Package: gij-3.1 Version: 1:3.1-2 Severity: normal gij-3.1 should provide java-runtime2. I found that I cant install libbtools-java because no package provides java-runtime2 except j2sdk1.3. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux asterix 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set) Versions of packages gij-3.1 depends on: ii gcc-3.1-base 1:3.1-2The GNU Compiler Collection (base ii libc6 2.2.5-6GNU C Library: Shared libraries an ii libgcc1 1:3.1-2GCC support library. ii libgcj3 1:3.1-2Java runtime library for use with ii zlib1g1:1.1.4-1 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148890: gcj-3.1: Error in manpage of gcj-3.1
Package: gcj-3.1 Version: 1:3.1.1-0pre1 Severity: normal The manpage of gcj-3.1 reads as following: -Idir All directories specified by "-I" are kept in order and prepended to the class path constructed from all the other options. Unless compatibility with tools like "javac" is imported, we recommend always using "-I" instead of the other options for manipulating the class path. I think "imported" should be replaced by "important". -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux asterix 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set) Versions of packages gcj-3.1 depends on: ii gcc-3.11:3.1.1-0pre1 The GNU C compiler. ii gcc-3.1-base 1:3.1.1-0pre1 The GNU Compiler Collection (base ii java-common0.14 Base of all Java packages ii libc6 2.2.5-6 GNU C Library: Shared libraries an ii libgcc11:3.1.1-0pre1 GCC support library. ii libgcj31:3.1.1-0pre1 Java runtime library for use with ii libgcj3-dev1:3.1.1-0pre1 Java development headers and stati ii zlib1g 1:1.1.4-1 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#149776: libstdc++4-dev: codecvt is missing some qualifications
Package: libstdc++4-dev
Version: 1:3.1.1-0pre1
Severity: normal
Tags: patch
The file /usr/include/g++-v3-3.1/i386-linux/bits/codecvt_specializations.h
(probably all other architectures as well) is missing some
qualifications that were already mentioned in Bug #104614.
Unfortunately, the patch was only made for libstdc++3-dev. Please
include this patch for libstdc++4.-dev as well:
--- codecvt_specializations.h-orig Wed Jun 12 17:04:54 2002
+++ codecvt_specializations.h Wed Jun 12 17:07:19 2002
@@ -260,7 +260,7 @@
extern_type* __to, extern_type* __to_end,
extern_type*& __to_next) const
{
- result __ret = error;
+ result __ret = codecvt_base::error;
if (__state._M_good())
{
typedef state_type::__desc_type __desc_type;
@@ -304,7 +304,7 @@
{
__from_next = reinterpret_cast(__cfrom);
__to_next = reinterpret_cast(__cto);
- __ret = ok;
+ __ret = codecvt_base::ok;
}
else
{
@@ -312,10 +312,10 @@
{
__from_next = reinterpret_cast(__cfrom);
__to_next = reinterpret_cast(__cto);
- __ret = partial;
+ __ret = codecvt_base::partial;
}
else
- __ret = error;
+ __ret = codecvt_base::error;
}
}
return __ret;
@@ -327,7 +327,7 @@
do_unshift(state_type& __state, extern_type* __to,
extern_type* __to_end, extern_type*& __to_next) const
{
- result __ret = error;
+ result __ret = codecvt_base::error;
if (__state._M_good())
{
typedef state_type::__desc_type __desc_type;
@@ -345,14 +345,14 @@
{
__to_next = reinterpret_cast(__cto);
if (__tlen == __tmultiple * (__to_end - __to))
- __ret = noconv;
+ __ret = codecvt_base::noconv;
else if (__tlen == 0)
- __ret = ok;
+ __ret = codecvt_base::ok;
else
- __ret = partial;
+ __ret = codecvt_base::partial;
}
else
- __ret = error;
+ __ret = codecvt_base::error;
}
return __ret;
}
@@ -365,7 +365,7 @@
intern_type* __to, intern_type* __to_end,
intern_type*& __to_next) const
{
- result __ret = error;
+ result __ret = codecvt_base::error;
if (__state._M_good())
{
typedef state_type::__desc_type __desc_type;
@@ -410,7 +410,7 @@
{
__from_next = reinterpret_cast(__cfrom);
__to_next = reinterpret_cast(__cto);
- __ret = ok;
+ __ret = codecvt_base::ok;
}
else
{
@@ -418,10 +418,10 @@
{
__from_next = reinterpret_cast(__cfrom);
__to_next = reinterpret_cast(__cto);
- __ret = partial;
+ __ret = codecvt_base::partial;
}
else
- __ret = error;
+ __ret = codecvt_base::error;
}
}
return __ret;
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux kosh 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8
Versions of packages libstdc++4-dev depends on:
ii g++-3.11:3.1.1-0pre1 The GNU C++ compiler.
ii gcc-3.1-base 1:3.1.1-0pre1 The GNU Compiler Collection (base
ii libc6-dev 2.2.5-6 GNU C Library: Development Librari
ii libstdc++4 1:3.1.1-0pre1 The GNU stdc++ library version 3
-- no debconf information
--
|=| Michael Piefel
|=| Humboldt-Universität zu Berlin
|=| Tel. (+49 30) 2093 3831
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problem with newer gcc
Hi, I'm maintaining tora, a program developed in C++. Now this works find with gcc 2.95, but there is a problem on hppa. It simply doesn't compile there with a strange error message. AFAIK hppa does use gcc 3+ as default so I tried with gcc 3.2 and I also can't get it to compile with error messages that I never saw in 2.95. Upstream, however, cannot find the error either, so maybe it's related to some changed in gcc or even a bug in gcc, I don't know. Could anyone of you please try to compile tora with gcc 3+ and look into the error messages? Please take the latest upload (1.3.7-4) since the earlier ones produced quite a lot of noisy warnings. Thanks a lot. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Latest upload did compile on hppa
Hi, I'm not sure why it worked this time, but the most recent CVS snapshot I uploaded as tora_1.3.7-4 did compile correctly on hppa as well I just learned. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: problem with newer gcc
On Tue, Sep 03, 2002 at 09:06:21PM +0200, Martin v. Loewis wrote: > It might be easier if you just report the errors that you get, perhaps > along with code fragments that the error messages refer to. As I'm not the upstream I do not know the code that well, so I thought it would be easier if you just try compiling the package on your machine. Anyway, I can surely create a log and send that. However, now that it compiled on gcc-3.0 or 3.1 I wonder if there are just some incompatibilities in the source code. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: how to find symbols needed for libgcc-compat in glibc
On Sat, Oct 12, 2002 at 02:58:44PM -0400, Jack Howarth wrote: Hi, >I'm not sure. I know I was told that hppa was okay. Also from my > conversations with Jakub it appears i386, ia-64, alpha and sparc32 > should be fine. So I would suggest we focus on checking the status > of arm, hurd-i386, m68k, mips, mipsel, s390 and sh. For m68k I found several libgcc symbols on my system using the script that was posted here. Someone will have to run a check over the whole archive, however I don't have the resources to do so. CCing m68k-build, any takers? -Michael
Re: Bug#164766: Problem with VIA C3 chip and libcrypto
On Fri, Jan 17, 2003 at 10:29:03AM -0500, Daniel Jacobowitz wrote: This libc ld.so special handling for hardware capability is used by only MMX currently. We expand it not only for MMX but also CMOV. MMX, intel's multi media extension, is also same circumstance that both Pentium (i586) and Pentium MMX (i586 MMX) are 'i586 class processors'. This bit is a good idea but... [snip] Let's not do anything about this until someone gets clarification from GCC that -march=i686 is not actually supposed to be a 686, OK? Why? Even if gcc didn't use cmov with -march=i686, is there another facility for using cmov in an optimized library? IOW, this ld.so extension sounds like something useful regardless of the state of gcc. Mike Stone
Re: binutils error? (autobuilder failure)
On Fri, Feb 07, 2003 at 07:32:46AM -0600, Stephen R Marenka wrote: Hi, > I've started seeing the following error on a number of builds, on two > different machines now. > > | dh_shlibdeps > | objdump: error while loading shared libraries: unexpected PLT reloc type > 0x00 > | dpkg-shlibdeps: failure: objdump on `debian/tmp/usr/bin/fbi' gave error > exit status 127 > | dh_shlibdeps: command returned error code 32512 > > It looks like a problem in binutils. Anyone else seen this? Do we need > to push for the patch (see below) in glibc? Are you sure that this would really fix anything? dpkg-shlibdeps uses objdump these days, not ldd, so I expect that this will need to be fixed in binutils. Btw. I was going to take a quick look at this, but I can't seem to get into the unstable chroot on crest. I thought those were supposed to be public? Or maybe I just haven't found the right command... -Michael > On Wed, Feb 05, 2003 at 12:28:20PM +0100, Richard Zidlicky wrote: > > On Wed, Feb 05, 2003 at 09:06:42AM +0100, Rene Engelhard wrote: > > > > > > Hi, > > > > > > [ please Cc: me, as I am not subscribed to -68k ] > > > > > > anyone of you know what causes the follwing build failure and what to do? > > > Versions till -3 built successfully; but binutils got updated > > > recently... > > > > > > http://buildd.debian.org/fetch.php?&pkg=firestarter&ver=0.9.1-4&arch=m68k&stamp=1044431895&file=log&as=raw > > > > known problem in binutils. Temporary workaround is to patch glibc > > like this: > > > > --- glibc-2.2.90/sysdeps/m68k/dl-machine.h.rz Mon Aug 26 11:44:44 2002 > > +++ glibc-2.2.90/sysdeps/m68k/dl-machine.h Mon Aug 26 11:45:31 2002 > > @@ -311,6 +311,8 @@ > >Elf32_Addr *const reloc_addr = (void *) (l_addr + reloc->r_offset); > >if (ELF32_R_TYPE (reloc->r_info) == R_68K_JMP_SLOT) > > *reloc_addr += l_addr; > > + else if (ELF32_R_TYPE (reloc->r_info) == R_68K_NONE) > > +return; > >else > > _dl_reloc_bad_type (map, ELF32_R_TYPE (reloc->r_info), 1); > > } > > > > No idea if it is fixed or going to be fixed in some newer binutils. > > The inefficiency introduced by this patch is minimal so it won´t > > hurt if it stays in glibc for a while. > > > > Richard
Bug#182795: gcc-3.2: mpqc build fails on MIPS with 'Branch out of range' error
Package: gcc-3.2 Version: 1:3.2.3-0pre2 Severity: normal Hi, compiling mpqc on MIPS results in this error: /usr/bin/gcc-3.2 -DHAVE_CONFIG_H -D_REENTRANT -I../../../../../src/lib -I/build/buildd/mpqc-2.1.3/include -I/build/buildd/mpqc-2.1.3/src/lib -O0 -Wall -c /build/buildd/mpqc-2.1.3/src/lib/chemistry/qc/dft/lebedev.c -o lebedev.o /tmp/ccIsYgSV.s: Assembler messages: /tmp/ccIsYgSV.s:361: Error: Branch out of range /tmp/ccIsYgSV.s:366: Error: Branch out of range [...] /tmp/ccIsYgSV.s:19541: Error: Branch out of range /tmp/ccIsYgSV.s:22425: Error: Branch out of range make[6]: *** [lebedev.o] Error 1 make[6]: Leaving directory `/build/buildd/mpqc-2.1.3/build-static/src/lib/chemistry/qc/dft' make[5]: *** [default] Error 1 make[5]: Leaving directory `/build/buildd/mpqc-2.1.3/build-static/src/lib/chemistry/qc' make[4]: *** [default] Error 1 make[4]: Leaving directory `/build/buildd/mpqc-2.1.3/build-static/src/lib/chemistry' make[3]: *** [default] Error 1 make[3]: Leaving directory `/build/buildd/mpqc-2.1.3/build-static/src/lib' make[2]: *** [default] Error 1 make[2]: Leaving directory `/build/buildd/mpqc-2.1.3/build-static/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/build/buildd/mpqc-2.1.3/build-static' make: *** [build-static-stamp] Error 2 see http://buildd.debian.org/fetch.php?&pkg=mpqc&ver=2.1.3-2&arch=mipsel&; \ stamp=104604&file=log&as=raw for the full buildd log. This error also occured on gcc-2.95, I did not file it earlier because I was hoping that it might be gone in gcc-3.2. The first builds in early 2002 were done with -O and then with -O0 afterwards. You can get the source file at http://people.debian.org/~mbanck/lebedev.c thanks, Michael
Re: Bug#183425: coreutils_4.5.8-1(m68k/unstable/poseidon): FTBFS on m68k
On Tue, Mar 04, 2003 at 02:14:32PM -0600, you wrote: coreutils fails to build from source on m68k, test failing. Well, it works everywhere else. GCC compile error? The test that's failing is the sha1sum validation, the source for which has not changed. Mike Stone
Bug#184141: package depends on LIBC_DEV
Package: libgcj3-dev When attempting to install this package, I get the following error message: Sorry, but the following packages have unmet dependencies: libgcj3-dev: Depends: LIBC_DEV but it is not installable I have libc6 and libc6-dev 2.3.1-14 installed. I'm guessing LIBC_DEV is an automake variable that should be determined when libgcj3-dev is built, but it could be something that libc6-dev should provide, or it could be there's something I still need to configure on my box. I am running Debian Unstable, installed 2003-02-10, on a AMD Athlon CPU.
Bug#189851: FTBFS on hurd-i386
Package: gcc-3.3 Version: 1:3.3ds5-0pre5 Severity: important Hi, I tried to build gcc-3.3 on hurd-i386. Unfortunately, sbuild died with 'Resource lost', probably a bug in hurd. I then did a debian/rules binary in the source tree and got the following error: : # rename files (versioned gpc man pages) for i in binobj gpc gpc-run gpidump; do \ mv debian/tmp/usr/share/man/man1/$i.1 \ debian/tmp/usr/share/man/man1/$i-2.1-3.3.1; \ done mv: cannot stat `debian/tmp/usr/share/man/man1/binobj.1': No such file or directory make[1]: *** [stamps/07-install-stamp] Error 1 make[1]: Leaving directory `/var/lib/buildd/build/mbanck/gcc-3.3-3.3ds5' make: *** [stamps/07-install-stamp] Error 2 After adding hurd-i386 to pascal_no_archs, the packages seem to have gotten created successfully, I did not test them yet. I tried to find out where binobj.1 get created, but got lost in the build-system/source-tree. cheers, Michael
Bug#191684: libstdc++5 3.3 breaks optimized binaries compiled with g++ 3.2
Package: libstdc++5
Version: 1:3.3-0pre7
Severity: important
After upgrading libstdc++5 from the 3.2 version to the 3.3 version, my
c++ binaries started to segfault. I traced the problem to this test
case:
#include
#include
using namespace std;
// Returns the argument as a string.
template
string to_string (T arg) {
ostringstream buffer;
buffer << arg;
return buffer.str();
}
int main () {
int num = 42;
printf("%s\n", to_string(num).c_str());
return 0;
}
Compile this with g++-3.2 -O3 -finline-limit=1000 and running it will
segfault. The same binary will work using the 3.2
libstdc++5. Compiling without optimization also works, as does
compiling with g++-3.3. However I believe it is important to maintain
binary compatibility in libstdc++5 with all the c++ code compiled with
g++ 3.2.
Here is a backtrace of the crash:
#0 0x4008b4a1 in bool std::has_facet
>(std::locale const&) () from /usr/lib/libstdc++.so.5
#1 0x4007e424 in std::ostreambuf_iterator
> std::num_put >
>::_M_convert_int(std::ostreambuf_iterator >, std::ios_base&, char, long) const () from
/usr/lib/libstdc++.so.5
#2 0x4007e178 in std::num_put > >::do_put(std::ostreambuf_iterator >, std::ios_base&, char, long) const () from
/usr/lib/libstdc++.so.5
#3 0x4009052f in std::ostream::operator<<(long) () from
/usr/lib/libstdc++.so.5
#4 0x08048d4b in main ()
#5 0x40110a51 in __libc_start_main () from /lib/libc.so.6
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux guinness 2.4.20-hpcs #1 SMP Mon Jan 27 10:13:02 PST 2003 i686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Versions of packages libstdc++5 depends on:
ii gcc-3.3-base 1:3.3-0pre7 The GNU Compiler Collection
(base
ii libc62.3.1-17GNU C Library: Shared
libraries an
ii libgcc1 1:3.3-0pre7 GCC support library
-- no debconf information
--
Michael Babcock
Jim Henson's Creature Shop
Bug#191684: http://ftp-master.debian.org/~doko/gcc-3.3/
That version (1:3.3ds8-0pre8) fixed it. Thanks.
Bug#445279: gcc-defaults: FTBFS on hurd-i386: libgcj-bc needs to be added to no_packages
Package: gcc-defaults Version: 1.61 Severity: important Tags: patch Hi, dh_builddeb expects libgcj-bc to be built as .deb, but it is excluded as part of gcj/gij not yet being available on hurd-i386. This leads to the following error: > dpkg-deb: building package `libgcj-common' in > `../libgcj-common_4.2-20070303-3_hurd-i386.deb'. > dpkg-deb: failed to open package info file > `debian/libgcj-bc/DEBIAN/control' for reading: No such file or > directory > dh_builddeb: command returned error code 512 > make: *** [binary-arch] Error 1 The attached patch fixes this, but maybe libgcj-common shouldn't be built either? Though I guess it doesn't hurt much on the other hand. thanks, Michael --- gcc-defaults-1.61/debian/rules 2007-09-02 22:46:50.43000 + +++ gcc-defaults-1.61+hurd.1/debian/rules 2007-10-04 10:00:10.14000 + @@ -186,7 +186,7 @@ ifeq ($(DEB_HOST_ARCH),hurd-i386) OS_NAME:= Hurd -no_packages += gnat gcj gij +no_packages += gnat gcj gij libgcj-bc endif ifeq ($(DEB_HOST_ARCH),ia64)
Bug#434937: gcc-4.2: Profiling on Hurd procudes a non-working executable
# same problem as with gcc-4.1/#433539 reopen 434937 thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#451520: gcc-4.2: [patch] support for fast-math on hurd-i386
Package: gcc-4.2
Version: 4.2.2-3
Severity: important
Hi,
the attached patch adds fast-math support for hurd-i386 to gcc-4.2 to as
well, it's slightly rediffed from the one for gcc-4.1, as that one does
not apply cleanly.
Please apply, several packages (most notably mesa) FTBFS without it.
thanks,
Michael
PS: If you prefer, I can maintain those hurd-specific patches in gcccvs
myself.
#! /bin/sh -e
# DP: Support -ffast-math on hurd-i386.
dir=
if [ $# -eq 3 -a "$2" = '-d' ]; then
pdir="-d $3"
dir="$3/"
elif [ $# -ne 1 ]; then
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
fi
case "$1" in
-patch)
patch $pdir -f --no-backup-if-mismatch -p0 < $0
;;
-unpatch)
patch $pdir -f --no-backup-if-mismatch -R -p0 < $0
;;
*)
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
esac
exit 0
--- gcc/config.gcc 2007-11-16 15:27:19.0 +0100
+++ gcc/config.gcc.new 2007-11-16 15:30:25.0 +0100
@@ -1109,6 +1109,7 @@
tmake_file="${tmake_file} i386/t-linux64 i386/t-crtstuff64 i386/t-crtfm
t-dfprules"
;;
i[34567]86-*-gnu*)
+ tmake_file="${tmake_file} i386/t-crtfm"
;;
i[34567]86-pc-msdosdjgpp*)
xm_file=i386/xm-djgpp.h
--- gcc-4.2-4.2.2/debian/rules.patch
+++ gcc-4.2-4.2.2/debian/rules.patch
@@ -60,6 +60,7 @@
arm-pr30486 \
arm-unbreak-eabi-armv4t \
hurd-profiling \
+ hurd-fast-math \
m68k-fjump \
m68k-save_pic \
m68k-dwarf \
Bug#458860: libstdc++6: Dependency on lib64gcc1 on i386
Package: libstdc++6 Version: 4.2.2-5 Severity: important The latest upgrade of libstdc++6 on i386 introduced a dependency on lib64gcc1, which in turn pulls libc6-amd64 (10Mb installed!). As my machine is i386 i.e. 32 bit only (pentium m) I don't want to have libc6-amd64 and lib64gcc1 installed. I checked the Debian Changelog but couldn't find any reference why this dependency was added. Please revert this change again. Cheers, Michael -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23.12 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libstdc++6 depends on: ii gcc-4.2-base 4.2.2-5The GNU Compiler Collection (base ii lib64gcc1 1:4.2.2-5 GCC support library (64bit) ii libc6 2.7-5 GNU C Library: Shared libraries libstdc++6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug Report Cyberjack Paket
Hallo, wenn ich versuche unter Sidux 2007-04.5 'libctapi-cyberjack2' zu installieren, gibt es ein Abhängigkeitsproblem mit apt. Der Output: libctapi-cyberjack2: Depends: libgcc1 (>= 1:4.2.1) but 1:4.2-20070525-1 is to be installed Depends: libstdc++6 (>= 4.2.1) but 4.2-20070525-1 is to be installed Dies Paketabhängigkeiten scheinen mir doch sehr seltsam. Es sieht so aus, als würde aufgrund der Namensgebung der installierten Pakete das libctapi-cyberjyck2 Paket nicht installiert werden. Dabei scheint mir doch die Versionsnummer OK zu sein. Aber auch wenn tatsächlich eine nicht erfüllte Abhängigkeit vorliegt, dann wunder mich das schon sehr, da ich doch nur die voreingestellten apt sourcen verwende. Sollten da nicht alle Paketabhängigkeiten erfüllt sein? Liebe Grüße, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397853: please recheck with gcc-4.3/g++-4.3/gcj-4.3 from unstable
> This bug report was submitted for an older version of gcc/g++/gcj. > Please recheck with the current gcc-4.3/g++-4.3/gcj-4.3 packages > from unstable. > So I did: corn:/tmp# javac -version gcj-4.3 (Debian 4.3-20080116-1) 4.3.0 20080116 (experimental) [trunk revision 131577] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. corn:/tmp# mkdir über corn:/tmp# cd über/ corn:/tmp/über# ls corn:/tmp/über# mkdir ha corn:/tmp/über# cd ha/ corn:/tmp/über/ha# vim Hello.java corn:/tmp/über/ha# javac Hello.java No .class file created for file Hello.class in /tmp/über/ha because of an IOException: /tmp/über/ha/Hello.class (No such file or directory) So, well, the diagnostic is somewhat better (it does not even compile...), but still it seems to be broken. Best, Michael pgpzC2DrflZRI.pgp Description: PGP signature
Bug#397853: NoClassDefFoundError in case the path contains umlauts
> Michael Tautschnig writes: > > Some investigations showed that the problem seems to be caused by a umlaut > > being > > contained in the directory name; if one copies the files to, e.g., /tmp/ > > things > > work fine. > > What locale are you using? How is the umlaut encoded in the directory > name? > As per the locale, this one should hopefully be helpful: corn:/tmp# locale LANG=en_US.ISO-8859-15 LC_CTYPE="en_US.ISO-8859-15" LC_NUMERIC="en_US.ISO-8859-15" LC_TIME="en_US.ISO-8859-15" LC_COLLATE="en_US.ISO-8859-15" LC_MONETARY="en_US.ISO-8859-15" LC_MESSAGES="en_US.ISO-8859-15" LC_PAPER="en_US.ISO-8859-15" LC_NAME="en_US.ISO-8859-15" LC_ADDRESS="en_US.ISO-8859-15" LC_TELEPHONE="en_US.ISO-8859-15" LC_MEASUREMENT="en_US.ISO-8859-15" LC_IDENTIFICATION="en_US.ISO-8859-15" LC_ALL= corn:/tmp# ls -la über/ total 12 drwxr-xr-x 3 root root 4096 2008-02-01 09:07 . drwxrwxrwt 5 root root 4096 2008-02-02 09:33 .. drwxr-xr-x 2 root root 4096 2008-02-01 09:07 ha However, what do you mean by the encoding? Just ISO-8859-15, or something else? Thanks, Michael pgpkvkP3Znvvm.pgp Description: PGP signature
binary compatibility with Debian...
Let me explain briefly the issue I've run into:
1. I build a really `short` application under Fedora or Mandrake disto(s):
int main()
{
return 0;
}
On both above platforms, it is build with command:
g++ -g -O0 -m32 test2.cpp,
where test2.cpp is a file with above mentioned code.
2. I move the binary output - a.out - to my Debian box.
Attempt to execute it is immediately failing with
`Floating point exception`.
3. Building above code on Debian and executing:
no problem - it is doing nothing, but not crashing...
4. moving the binary, build on Debian to Fedora and/or Mandriva-
and running it - no problem, doing nothing, not crashing.
I would really appreciate any idea how to explain such behavior, and,
possibly, an advice what should be done in order to share binary,
build on Fedora/Mandriva with Debian.
Thanks for you kind attention to this matter.
Bug#489234: patch to allow gnu99 mode on m68k
Package: gcc-4.3
Version: 4.3.1-2
Severity: important
Tags: patch
On m68k, gnu99 mode doesn't work correctly out of the box due to our
woefully outdated glibc (we're currently stuck at 2.5-1). This is because
the inline schematics changed between glibc 2.5 and 2.7, and gcc 4.2 to 4.3.
This patch configures the built in spec file to pass -fgnu89-inline, and
thus allowing
proper compilation and linking with the older glibc on m68k. This patch
should not be
merged upstream, and it should be removed once a newer glibc is available
for our architecture.
Michael
--- linux-old.h2008-07-04 04:02:21.0 -0400
+++ linux.h2008-07-04 05:23:21.0 -0400
@@ -37,6 +37,13 @@
#undef M68K_HONOR_TARGET_STRICT_ALIGNMENT
#define M68K_HONOR_TARGET_STRICT_ALIGNMENT 0
+/* on m68k, we always need to use gnu89 inlining because we're
+ still limited to glibc 2.5. This should be removed after
+ a newer glibc is available */
+
+#undef CC1_SPEC
+#define CC1_SPEC "%{profile:-p} %{std=gnu99:-fgnu89-inline}"
+
/* Here are four prefixes that are used by asm_fprintf to
facilitate customization for alternate assembler syntaxes.
Machines with no likelihood of an alternate syntax need not
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gcc-4.3 depends on:
ii binutils2.18.1~cvs20080103-4 The GNU assembler, linker and
bina
ii cpp-4.3 4.3.1-2 The GNU C preprocessor
ii gcc-4.3-base4.3.1-2 The GNU Compiler Collection
(base
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libgcc1 1:4.3.1-2GCC support library
ii libgomp14.3.1-2 GCC OpenMP (GOMP) support
library
Versions of packages gcc-4.3 recommends:
ii libc6-dev 2.7-10 GNU C Library: Development
Librari
-- no debconf information
Bug#489234: *sigh*
X-Debbugs-CC: [EMAIL PROTECTED]
I should not send patches when I'm half alseep. Here's one that's actually
appliable ;-)
--- gcc-4.3.1/gcc/config/m68k/linux-old.h2008-07-04 04:02:21.0
-0400
+++ gcc-4.3.1/gcc/config/m68k/linux.h2008-07-04 05:23:21.0 -0400
@@ -37,6 +37,13 @@
#undef M68K_HONOR_TARGET_STRICT_ALIGNMENT
#define M68K_HONOR_TARGET_STRICT_ALIGNMENT 0
+/* on m68k, we always need to use gnu89 inlining because we're
+ still limited to glibc 2.5. This should be removed after
+ a newer glibc is available */
+
+#undef CC1_SPEC
+#define CC1_SPEC "%{profile:-p} %{std=gnu99:-fgnu89-inline}"
+
/* Here are four prefixes that are used by asm_fprintf to
facilitate customization for alternate assembler syntaxes.
Machines with no likelihood of an alternate syntax need not
Bug#491137: [g++/s390 only] optimization causes errornous behavior
Package: g++-4.3
Version: 4.3.1-4
[I leave it to the gcc maintainers to judge about the severity, because it
actually breaks otherwise running programs, but those cases seem extremely rare]
When rebuilding diagnostics, it failed on s390 during the selftests [0]. The
failing piece of code is attached. This is not actually a tiny example, but all
attempts of reducing this further failed to reproduce the error. This is a
regression because it does not fail on g++-4.2. The compiler command lines to
reproduce are:
g++ -O -fgcse -DDEBUG__LEVEL__=2 invariance_annotation.t.cpp -ldiagnostics -o
invbuggy
./invbuggy run "/*" 2
whereat we would expect to see no failure, instead of a MISSING_EXCEPTION [TES]:
...
Please note that replacing -O by
-fomit-frame-pointer \
-fauto-inc-dec \
-fcprop-registers \
-fdce \
-fdefer-pop \
-fdelayed-branch \
-fdse \
-fguess-branch-probability \
-fif-conversion2 \
-fif-conversion \
-finline-small-functions \
-fipa-pure-const \
-fipa-reference \
-fmerge-constants \
-fsplit-wide-types \
-ftree-ccp \
-ftree-ch \
-ftree-copyrename \
-ftree-dce \
-ftree-dominator-opts \
-ftree-dse \
-ftree-fre \
-ftree-sra \
-ftree-ter \
-funit-at-a-time
(all controllable options enabled by -O) does _not_ yield the errornous
behavior, and dropping -fgcse also stops the runtime failure.
Attached please find the cleaned source file. All attempts of reproducing the
error were made on raptor.d.o. If there is anything more that I could do to
debug this issue, please contact me.
Best,
Michael
[0]
http://buildd.debian.org/fetch.cgi?&pkg=diagnostics&ver=0.2.2%2Bb1&arch=s390&stamp=1214648343&file=log
#include
// component
#include
#define TEST_COMPONENT_NAME invariance_annotation
#define TEST_COMPONENT_NAMESPACE diagnostics
DIAGNOSTICS_NAMESPACE_BEGIN;
TEST_NAMESPACE_BEGIN;
TEST_COMPONENT_TEST_NAMESPACE_BEGIN;
using namespace unittest;
class Dummy_Class_With_Invariance
{
typedef Dummy_Class_With_Invariance Self;
public:
Dummy_Class_With_Invariance()
: m_class_invariance_called(0),
m_throw(false)
{
}
void method_with_guard(bool const t1,
bool const t2)
{
m_class_invariance_called=0;
m_throw=t1;
::diagnostics::internal::Class_Invariance_Guard_Throw g(this);
m_throw=t2;
}
void m_class_invariance() const
{
++m_class_invariance_called;
if(m_throw) throw Test_Exception("Invariance throwing");
}
int class_invariance_called() const
{
return m_class_invariance_called;
}
private:
mutable int m_class_invariance_called;
bool m_throw;
};
void guard(Test_Data & data)
{
Dummy_Class_With_Invariance d;
TEST_EXCEPTIONLESS_BLOCK_ENTER;
d.method_with_guard(false,false);
TEST_EXCEPTIONLESS_BLOCK_EXIT;
TEST_ASSERT(d.class_invariance_called()==2);
TEST_THROWING_BLOCK_ENTER;
d.method_with_guard(true,true);
TEST_THROWING_BLOCK_EXIT1(Test_Exception,::std::string("Invariance
throwing").c_str());
TEST_ASSERT(d.class_invariance_called()==1);
TEST_THROWING_BLOCK_ENTER;
d.method_with_guard(false,true);
TEST_THROWING_BLOCK_EXIT1(Test_Exception,::std::string("Invariance
throwing").c_str());
TEST_ASSERT(d.class_invariance_called()==2);
}
TEST_COMPONENT_TEST_NAMESPACE_END;
TEST_NAMESPACE_END;
DIAGNOSTICS_NAMESPACE_END;
TEST_SUITE_BEGIN;
TEST_NORMAL_CASE(&guard,LEVEL_PROD);
TEST_SUITE_END;
STREAM_TEST_SYSTEM_MAIN;
// vim:ts=4:sw=4
pgpYZBqq8OmW6.pgp
Description: PGP signature
Bug#494815: gcc 4.3.1: some code breaks when optimization is not -O0
Package: gcc Version: 4.3.1 Severity: important As explained at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37090 the GCC in version 4.3.1 produces broken code for some loops. Please upgrade GCC to a newer version before freezing lenny to stable, because we otherwise have to use/add workarounds for software on debian stable because it uses GCC 4.3.1. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498934: priority required still necessary?
Package: gcc-4.2-base Version: 4.2.4-3 Severity: normal I was wondering why gcc-4.2-base is priority required given that gcc-4.3-base is around which already is priority required. The other gcc-*-base packages, like gcc-4.1-base and gcc-3.4-base, have priority optional. Should be priority of gcc-4.2-base be demoted to optional? Michael -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.27-rc6 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ppl - source package should be versioned
> Assume we do build the default gcc depending on a libppl0, now the > libppl soname is changed to libppl1, a new ppl source is uploaded, and > suddendly libppl0 isn't available anymore. And we still need to > rebuild gcc using gcc. Making the ppl source versioned (pplX), we > still have the old libppl0 in the archive, and can rebuild gcc, then > remove the old pplX source and binary packages only built from the old > source. Please consider this for the next version bump. > Does gcc indeed build-depend on libpplX/libppl-cX? If this is not the case, all that must be taken care of is transitions to testing, if I'm not mistaken. Or am I getting something wrong? Thanks, Michael pgp6yyAlRUErN.pgp Description: PGP signature
Re: ppl - source package should be versioned
> Michael Tautschnig writes: > > > Assume we do build the default gcc depending on a libppl0, now the > > > libppl soname is changed to libppl1, a new ppl source is uploaded, and > > > suddendly libppl0 isn't available anymore. And we still need to > > > rebuild gcc using gcc. Making the ppl source versioned (pplX), we > > > still have the old libppl0 in the archive, and can rebuild gcc, then > > > remove the old pplX source and binary packages only built from the old > > > source. Please consider this for the next version bump. > > > > > > > Does gcc indeed build-depend on libpplX/libppl-cX? If this is not the case, > > all > > that must be taken care of is transitions to testing, if I'm not mistaken. > > Or am > > I getting something wrong? > > yes. while you may have the old libppl0 still installed in the > archive, a buildd cannot find it anymore in the archive, if it is not > installed anymore in the buildd chroot. > Sure, sorry for overlooking that point. What troubles me a bit is that I fail to find any package already doing that kind of stuff to find a bit of information on dos and don'ts. After all, gcc-snapshot depends on a quite large set of libraries, all of which should stumble over this issue at some point!? But apparently the only alternative seem to be version symbols and to build multiple versions of the library from a single package. Best, Michael pgpjcDaIiMVEl.pgp Description: PGP signature
Bug#499746: Building still fails on ARM
Dear developers, apparently ppl 0.10 pre34 still fails to build on some architectures because of FPU_* macros not being defined. Please see http://buildd.debian.org/fetch.cgi?&pkg=ppl&ver=0.10~pre34-1&arch=arm&stamp=1223724338&file=log for details. Thanks, Michael pgp65RWiokeLZ.pgp Description: PGP signature
Bug#499746: [PPL-devel] Building still fails on ARM
> Michael Tautschnig wrote: >> apparently ppl 0.10 pre34 still fails to build on some architectures because >> of >> FPU_* macros not being defined. Please see >> http://buildd.debian.org/fetch.cgi?&pkg=ppl&ver=0.10~pre34-1&arch=arm&stamp=1223724338&file=log >> for details. > > Hi Michael, > > yes, we received numerous messages on the subject. > We are working on the issue. Would it be possible > to set up an access to an ARM machine? > All the best, > I've posted a request on debian-arm [1], in case we don't see a response soon I could try to do the debugging for you on Thursday afternoon. As such, any proposed patches and pointers would be great. Best, Michael [1] http://lists.debian.org/debian-arm/2008/10/msg00031.html pgprkm7TixQ9k.pgp Description: PGP signature
Bug#491137: [g++/s390 only] optimization causes errornous behavior
Hi Bastian, Thanks for replying and checking stuff. > On Thu, Jul 17, 2008 at 03:34:59AM +0200, Michael Tautschnig wrote: > > When rebuilding diagnostics, it failed on s390 during the selftests [0]. The > > failing piece of code is attached. > > This includes too many preprocessor magic. Please provide an example > without. > I tried to, but the slightest modification of the code made me unable to reproduce the bug. I'm well aware of the fact that this makes it more or less impossible to diagnose the problem. > I was not even able to link libdiagnostics properly because it include > unresolvable symbols. > Huh? That should not happen. Could you provide some details? Probably a bug to be filed against diagnostics or just communicate in PM as it does not belong to this report, but it'd be interesting nevertheless. > Anyway, the access to m_throw as class member is somehow screwed if both > m_class_invariance and the destructor of Dummy_Class_With_Invariance is > inline. > I don't really get what you're after. Why actually is there a problem with that? The destructor is not defined, so it will be generated, but it will be a no-op anyway. Why does inlining play a specific role here? > > (all controllable options enabled by -O) does _not_ yield the errornous > > behavior, and dropping -fgcse also stops the runtime failure. > > -fgcse is not the root cause. -O0 -fgcse does not show this behaviour. > Ok, so it is some interplay of optimizations, which makes it more or less impossible to debug. I guess there is no other option than waiting for next gcc upload to become available in unstable so I can re-check on raptor.d.o. Nevertheless, it would be interesting to get some more details on your suspections noted above. Thanks, Michael pgpdriAyTc3En.pgp Description: PGP signature
Bug#508576: gcc-4.3: internal compiler error: Segmentation fault (reproducible)
Package: gcc-4.3 Version: 4.3.2-1 Severity: important gcc stops with an internal compiler error when compiling mplayer 2008-12-12 snapshot. cc -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -mcpu=970 -mtune=970 -pipe -ffast-math -fomit-frame-pointer -maltivec -mabi=altivec -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/include/directfb -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -c -o libmpcodecs/ad_imaadpcm.o libmpcodecs/ad_imaadpcm.c libmpcodecs/ad_imaadpcm.c: In function 'qt_ima_adpcm_decode_block': libmpcodecs/ad_imaadpcm.c:207: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [libmpcodecs/ad_imaadpcm.o] Error 1 m...@homer:~/mplayer-export-2008-12-12$ The error is 100% reproducible, so it is not a hardware failure. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc64) Kernel: Linux 2.6.26-1-powerpc64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.3 depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii cpp-4.3 4.3.2-1 The GNU C preprocessor ii gcc-4.3-base4.3.2-1 The GNU Compiler Collection (base ii libc6 2.7-16 GNU C Library: Shared libraries ii libgcc1 1:4.3.2-1GCC support library ii libgomp14.3.2-1 GCC OpenMP (GOMP) support library Versions of packages gcc-4.3 recommends: ii libc6-dev 2.7-16 GNU C Library: Development Librari Versions of packages gcc-4.3 suggests: pn gcc-4.3-doc(no description available) pn gcc-4.3-locales(no description available) pn gcc-4.3-multilib (no description available) pn libgcc1-dbg(no description available) pn libgomp1-dbg (no description available) pn libmudflap0-4.3-dev(no description available) pn libmudflap0-dbg(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#491137: Small example to reproduce the bug
found 491137 4.3.3-1
thanks
Finally I got around to produce a tiny example from the original code that
reproduces the bug. The attached code contains several notes on which parts seem
to be essential (e.g., using ::std::string in some way). To reproduce do
g++ -g -O2 -o invariance_annotation invariance_annotation.preproc.cpp
./invariance_annotation
vs.
g++ -g -O2 -DVOLATILE -o invariance_annotation invariance_annotation.preproc.cpp
./invariance_annotation
All experiments were done in the sid chroot on zelenka.d.o.
Hope this helps,
Michael
// try:
// g++ -O2 -o invariance_annotation invariance_annotation.preproc.cpp ;
./invariance_annotation
// g++ -O2 -DVOLATILE -o invariance_annotation
invariance_annotation.preproc.cpp ; ./invariance_annotation
// Was fine on g++ 4.2, only happens on s390; adding -g does not change the
behaviour
struct Dummy_Class_With_Invariance;
struct Class_Invariance_Guard_Throw
{
explicit Class_Invariance_Guard_Throw(Dummy_Class_With_Invariance *
object);
~Class_Invariance_Guard_Throw();
Dummy_Class_With_Invariance & m_object;
};
struct Dummy_Class_With_Invariance
{
void method_with_return(bool t1, bool t2)
{
m_class_invariance_called=0;
m_throw=t1;
Class_Invariance_Guard_Throw internal__invariance_guard(this);
m_throw=t2;
return;
// internal__invariance_guard is destructed at this point and
must thus call m_class_invariance
}
void m_class_invariance()
{
++m_class_invariance_called;
if(m_throw) throw "Invariance throwing";
}
int m_class_invariance_called;
#ifdef VOLATILE
volatile
#endif
bool m_throw;
};
Class_Invariance_Guard_Throw::Class_Invariance_Guard_Throw(Dummy_Class_With_Invariance
* object)
: m_object(*object)
{
(m_object.m_class_invariance)();
}
Class_Invariance_Guard_Throw::~Class_Invariance_Guard_Throw() {
(m_object.m_class_invariance)();
}
#include
int main()
{
Dummy_Class_With_Invariance d;
d.method_with_return(false,false);
if(!(d.m_class_invariance_called==2)) {
// use of ::std::string or other class (implicitly) building a
string from the argument
// required to cause the error
throw ::std::string("d.m_class_invariance_called==2");
}
d.method_with_return(false,false);
if(!(d.m_class_invariance_called==2)) {
// use of ::std::string or other class (implicitly) building a
string from the argument
// required to cause the error
throw ::std::string("d.m_class_invariance_called==2");
}
try {
d.method_with_return(false,true);
printf("Missing exception\n");
} catch(...) {
printf("Ok\n");
}
}
pgpNvcC5SzR1Z.pgp
Description: PGP signature
Bug#514158: ppl is broken on bigendian systems
Package: ppl Version: 0.10-1 Severity: serious Justification: Package is unusable on a number of architectures Tags: upstream It has been brought to our attention that ppl 0.10-1 is broken on all bigendian systems. All floating point computations will (silently) use wrong results, which makes the package barely useable in that case. Upstream already has a patch in CVS that will be picked up for 0.10-2. Best, Michael pgpiSWAzikuvn.pgp Description: PGP signature
Bug#516419: ppl_0.10-3(mips/unstable):
> Package: ppl > Version: 0.10-3 > Severity: serious > > There was an error while trying to autobuild your package: > [...] Yes, thanks, already noticed; in fact, I uploaded a version supposed to fix this an hour ago. I'll close this bug tomorrow, once autobuilding has confirmed that my fix is appropriate. Thanks again and sorry for the noise, Michael pgpBfDmeBqKQQ.pgp Description: PGP signature
Bug#517659: ppl - FTBFS: Missuse of buildd resources
Hi Bastian, > Bastian Blank wrote: >> Package: ppl >> Version: 0.10-4 >> Severity: serious >> As I hate playing with severities: I'd ask you to reconsider the severity after reading those mails, I'd prefer not to change it myself to avoid any kind of ping-pong. >> The build of ppl needs 7 CPU-hours on a fast machine, including a long >> documentation run. > > This is probably due to `make check', which is something you can disable > if you are prepared to accept the risk of miscompilation of the library > (something that has just happened on Debian/Alpha). > > You should take into account that we use the PPL to validate > mission-critical software. Consequently, our `make check' is very > thorough. For PPL 0.11 we will probably add a `make quick-check' > feature, but we will certainly not use it ourselves (because we know > no single test in `make check' is truly superfluous). > Our debian/rules understands the nocheck build option, so there is already a Debian-standard way of disabling that, but I have no idead whether buildd's software supports that. I'd also ask Bastian to acknowledge the importance of the suite as ppl is a (future) dependency of gcc, which is of uttermost importance to other package builds. In the past we had ignored problems during make check which caused a big-endian problem to slip through that would have been spotting by the test suite. As such, the test suite really seems useful, especially with Debian's broad range of platforms. > Concerning the documentation, we use Doxygen to build the library's > documentation. I don't know which subset of the available manuals > the Debian package builds. In the past it was building also the > developer's reference manual, something we advised against. Moreover, > the instantiation-independent documentation is shipped with the > library and there is no need to rebuild it. > We only build the user-docs nowadays, and that actually wouldn't be necessary if Debian's build system did what the policy says: There is no need to re-build the architecture independent stuff on each and every host, but the buildd software does not yet properly use the build-arch target. If it did, we could get rid of all the dependencies (the TeX stuff, doxygen and some others) that needn't get installed and would spare the documentation building time. Bastian, if there is some other nice way to work around the build-arch problem, please let me know. > Anyway, if it really takes 7 hours perhaps there is some other problem > or I would not call the machine "a fast machine". Configuring the PPL > with --enable-interfaces"c c++" (which is what I believe Debian does) > `make check' takes less than 3 hours on our main server (`make -j 8 check' > takes less than 34 minutes). > Maybe the disks are a little slower and some other overhead -> I think twice your build time does not immediately mean that there is a problem, unless your main server is something you consider slow already. [...] Bastian, at the moment I don't see any other option than kindly asking you to accept the situation. I'll do my best to keep the frequency of uploads as low as possible such as not to block the buildds for too long. If you see any option for improvements I'm of course open to integrate them with the build rules of the ppl package. Thanks, Michael pgpzDIGs8pidP.pgp Description: PGP signature
Bug#517659: ppl - FTBFS: Missuse of buildd resources
> Julien Cristau wrote: > > On Mon, Mar 2, 2009 at 23:22:36 +0100, Michael Tautschnig wrote: > > > >> We only build the user-docs nowadays, and that actually wouldn't be > >> necessary if > >> Debian's build system did what the policy says: There is no need to > >> re-build the > >> architecture independent stuff on each and every host, but the buildd > >> software > >> does not yet properly use the build-arch target. If it did, we could get > >> rid of > >> all the dependencies (the TeX stuff, doxygen and some others) that needn't > >> get > >> installed and would spare the documentation building time. Bastian, if > >> there is > >> some other nice way to work around the build-arch problem, please let me > >> know. > >> > > build the docs in the binary-indep target instead of build. > > And make sure that build dependencies that are only needed for > binary-indep are in Build-Depends-Indep > Just to let everyone know (and with the hope that there is no disagreement with this): I plan to close this bug by fixing debian/rules and debian/control as suggested above, but I'm not going to do anything about the long test suite runs. Best, Michael pgpDsykPsmflD.pgp Description: PGP signature
Bug#528840: gcc-4.3: ICE when compiling rsyslog on powerpc
Package: gcc-4.3 Version: 4.3.3-10 Severity: serious Justification: causes package to ftbfs Hi, currently rsyslog ftbfs on powerpc due to a ICE. See https://buildd.debian.org/fetch.cgi?&pkg=rsyslog&ver=3.22.0-1&arch=powerpc&stamp=1242425299&file=log for details. Cheers, Michael -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29.3 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gcc-4.3 depends on: ii binutils 2.19.1-1 The GNU assembler, linker and bina ii cpp-4.3 4.3.3-10 The GNU C preprocessor ii gcc-4.3-base 4.3.3-10 The GNU Compiler Collection (base ii libc6 2.9-12 GNU C Library: Shared libraries ii libgcc1 1:4.4.0-4 GCC support library Versions of packages gcc-4.3 recommends: ii libc6-dev 2.9-12 GNU C Library: Development Librari Versions of packages gcc-4.3 suggests: pn gcc-4.3-doc(no description available) pn gcc-4.3-locales(no description available) pn gcc-4.3-multilib (no description available) pn libgcc1-dbg(no description available) pn libgomp1-dbg (no description available) pn libmudflap0-4.3-dev(no description available) pn libmudflap0-dbg(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
segfault with bitfields in structs
>Submitter-Id: net
>Originator:Michael Walle
>Organization:
>Confidential: no
>Synopsis: segfault with bitfields in structs
>Severity: serious
>Priority: medium
>Category: c
>Class: ice-on-legal-code
>Release: gcc (Debian 4.3.2-1.1) 4.3.2
>Environment:
System: Linux thanatos 2.6.26-2-686-bigmem #1 SMP Thu Mar 26 02:03:34 UTC 2009
i686 GNU/Linux
>Description:
Compiling the following (nonsense but valid) code triggers an internal
compiler error.
>How-To-Repeat:
Compile the following:
-- snip --
struct s {
unsigned int a : 4;
unsigned int b : 28;
};
void f()
{
char c;
struct s s;
s.a = (c >> 4) & ~(1<<4);
}
-- snip --
$ gcc -Wall -c bug.c
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See for instructions.
>Fix:
not known
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532821: [Pkg-utopia-maintainers] Bug#528145: Bug#528145: Bug#528145: dbus start script segmentation fault
reassign 532821 binutils found 532821 2.19.1-1 block 528145 by 532821 thanks Michael Biebl wrote: > I'm cloning the bug for gcc, because this is (one of) the packages of the > build > toolchain that was updated between the 1.2.12-1 and 1.2.14-2 build of dbus. > The > last upload of binutils was before dbus 1.2.12-1, and this binary was still > working. I narrowed down the problem and it seems my guess with gcc was wrong. On an up-to-date sid system and binutils from lenny, the resulting binary works correctly. Thus it seems to be a regression in binutils, so reassigning. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#593324: [armel] g++-4.4 -O1 makes ppl test suite fail
Package: g++-4.4 Version: 4.4.4-8 (Leaving choice of severity to gcc maintainers; at the current stage ppl cannot migrate to testing although it would fix an RC bug.) ppl 0.10.2-7 FTBS on armel [1] (exclusively) with test suite failures; this was extremely surprising as 0.10.2-6 was fine [2] and there were no code changes. Still, the failure turned out to be reproducible on abel.d.o. Looking at one of the failures (tests/Octagonal_Shape/upperboundifexact1.cc, disabled all but test02, test03, test04, using cmdline [3]) yields the following interesting result: - Changing optimization to -O0 makes things work. - Using -O1 or -O2 causes the failure. - Using -O3 makes things work again. - Using all the -f... options that "g++ -O1 -Q --help=optimizers" claims to be enabled at -O1 does not induce the failure. At this point I feel unable to debug this any further because I do not know which more fine-grained options to add to see which (set of) optimization triggers the problem. I might want to add that 0.10.2-6 was built using g++-4.4 4.4.3-1 (successful), 0.10.2-7 failed with g++-4.4 4.4.4-8. Using the command line as shown in [3] the error is pretty easy to see; correct and stated in the test suite is === test02 === *** octs1 *** A >= -2, A <= -1, B >= 0, B <= 2 *** octs2 *** A >= 1, A <= 2, B >= 0, B <= 2 but we get === test02 === *** octs1 *** A >= -2, A <= 4294967295, B >= 0, B <= 2 *** octs2 *** A >= -4294967295, A <= 2, B >= 0, B <= 2 Please let me know if there's anything else I can do; the complete sources are still there on abel.d.o. Best regards, Michael [1] https://buildd.debian.org/fetch.cgi?&pkg=ppl&ver=0.10.2-7&arch=armel&stamp=1280947057&file=log [2] https://buildd.debian.org/fetch.cgi?&pkg=ppl&ver=0.10.2-6&arch=armel&stamp=1267963469&file=log [3] touch upperboundifexact1.cc ; make upperboundifexact1 \ TEST_CPPFLAGS="-DOCTAGONAL_SHAPE_INSTANCE=int64_t -DNOISY -DVERY_NOISY" \ CXXFLAGS="-frounding-math -g -O2" ; PPL_NOISY_TESTS=1 ./upperboundifexact1 pgpoHooU3AOpB.pgp Description: PGP signature
Bug#595884: ppl: FTBFS in squeeze: /bin/bash: plld: command not found
tags 595884 - sid fixed 595884 0.10.2-7 thanks [...] > > plld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ > > -ld x86_64-linux-gnu-g++ \ > > -ld-options`echo '' -g -O2 -frounding-math -g -O2 -W -Wall | > > tr " " "/"` \ > > -o ppl_pl .libs/libppl_swiprolog.a ppl_pl.o \ > > -L../../../src/.libs \ > > -lppl -L../../../Watchdog/src/.libs -lpwl -lm -L/usr/lib > > -lgmpxx -L/usr/lib -lgmp > > /bin/bash: plld: command not found > > make[7]: *** [ppl_pl] Error 127 > > The full build log is available from: > > http://people.debian.org/~lucas/logs/2010/09/06/ppl_0.10.2-6_lsqueeze64.buildlog > > It is possible that your package builds fine in sid, but you should make sure > that your package also builds fine in squeeze before the release. > [...] Thanks for checking; this bug has already been fixed in 0.10.2-7 (and 0.10.2-8 should now also be ready for later migration to squeeze). Best, Michael pgpOI0fK4T5S0.pgp Description: PGP signature
Re: Processed: tagging 595884
Hi Julien, > Processing commands for cont...@bugs.debian.org: > > > tags 595884 + sid > Bug #595884 [ppl] ppl: FTBFS in squeeze: /bin/bash: plld: command not found > Added tag(s) sid. Would you mind elaborating why you re-added the sid tag? This bug is already fixed in the version(s) in sid!? Thanks a lot, Michael pgp48wvmEuOUf.pgp Description: PGP signature
Bug#601445: FTBFS on m68k: swipl-ld: command not found
> Source: ppl > Version: 0.10.2-8 > Severity: important > > Hi, > > apparently, the build dependencies are not tight enough. > Running cowbuilder --debbuildopts -B --binary-arch --build > ppl_0.10.2-8.dsc fails (after a day and a half, mind you) > with: > [...] > /bin/bash: swipl-ld: command not found [...] > > May I suggest to disable (for now) the Prolog interface on m68k, > as it’s in a sort-of rebootstrapping process anyway? > Thanks a lot for looking into this; I'll try to fix this ASAP. Indeed I hadn't expected any architectures to have older swi-prolog versions lingering around. Best, Michael pgpI1bUjiz6rK.pgp Description: PGP signature
Re: ppl_0.11-1_amd64.changes ACCEPTED into experimental
> while you do provide versioned -dev packages, you didn't rename the > source package, so currently only 0.10 or 0.11 will be available. > Not sure if I do want to backport the ppl 0.11 support to 4.4 and > 4.5. > [...] Is there actually any backporting work necessary, or is it just recompiling? I'll of course check this myself if you could just give me any hints which package to try to build and, if you already know of any, which obstacles I might find. Thanks a lot, Michael pgp6zbff3mryN.pgp Description: PGP signature
Re: ppl_0.11-1_amd64.changes ACCEPTED into experimental
Hi Matthias, Thanks a lot for getting back to me. [...] > > > >Is there actually any backporting work necessary, or is it just recompiling? > >I'll of course check this myself if you could just give me any hints which > >package to try to build and, if you already know of any, which obstacles I > >might > >find. > > the old cloog-ppl won't be developed further. If you could check > that the current cloog-ppl still builds and works with the current > ppl, and you can assure this for the lifetime of gcc-4.4 in > unstable, then you maybe can build from the same source. If not, > maybe renaming the source is easier ;) > Could you please only let me know which versions you refer to as "old" and "new"? It seems that Debian has 0.15.9 while on the homepage of cloog I can only find 0.14.1 (and git even has only 0.14.0 tagged) and some "Development Version." Thanks a lot, Michael pgpPqXiYgAuXG.pgp Description: PGP signature
Re: ppl_0.11-1_amd64.changes ACCEPTED into experimental
[...] > > see the GCC build requirements where to download 0.15.9. 0.15.10 > just contains a consistency check, no need to update. > [...] 0.15.10 compiles fine with ppl 0.11 and passes all tests. Given that Roberto Bagnara, head of PPL development, seems to be actively working with cloog developers I don't expect this to change any time soon. Best regards, Michael pgpnIEUr2UezV.pgp Description: PGP signature
Bug#604774: Powerpc compilation error
reopen 604774
thanks
I still get compilation errors with the latest version. Apparently this
is caused by not having the complete initial patch applied which also
removes the setting of the LD_LIBRARY_PATH.
SET_CROSS_LIB_PATH =
LD_LIBRARY_PATH=$${LD_LIBRARY_PATH:+$$LD_LIBRARY_PATH:}/$(PF)/$(DEB_TARGET_GNU_TYPE)/lib
Because of that I get the following error messages during the build.
sed -i s/-powerpc-cross//g debian/libgcc1-powerpc-cross/DEBIAN/shlibs
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}/usr/powerpc-linux-gnu/lib
ARCH=powerpc MAKEFLAGS="CC=something" dh_shlibdeps
-plibgcc1-powerpc-cross
/usr/bin/perl: error while loading shared libraries:
/usr/powerpc-linux-gnu/lib/libdl.so.2: ELF file data encoding not
little-endian
make[1]: *** [stamps/08-binary-stamp-libgcc] Error 127
Commenting SET_CROSS_LIB_PATH fixes the problem for me.
Kind regards,
Michael
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101201101608.ga31...@gibson.comsick.at
Bug#606277: Please add Recommends: latex-xcolor
> this is included by doxygen.sty in ppl. > Thanks for fixing doxygen in this respect! > See https://bugzilla.gnome.org/show_bug.cgi?id=638661 > for another missing include > Do you mean texlive-math-extra? Could you provide some further information what was failing before you added it? Thanks a lot, Michael pgpLmm7HIeqA8.pgp Description: PGP signature
Re: gcc build failures on alpha
On 21/03/11 04:16, Matthias Klose wrote: https://buildd.debian.org/status/package.php?p=gcc-snapshot fails to build with a link error. That's the GPREL16 relocation truncation error which is reputedly due to a bug in the linker optimiser. Linking with -Wl,--no-relax resolves those (presumably producing suboptimal, but at least working, code). Cheers Michael. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d87125c.1040...@orcon.net.nz
Re: Bug#620716: libppl0.10-dev not in unstable anymore
> On Sun, Apr 3, 2011 at 18:20:09 +0200, Matthias Klose wrote: > > > Package: libapron-dev > > Version:0.9.10-5 > > Severity: serious > > > > libapron-dev depends on libppl0.10-dev, which doesn't exist anymore in > > unstable, now removed by ftp-master. Please depend on libppl0.11-dev > > instead. > > > Well. Or libppl-dev, so you don't break next time. Why are the > libppl dev packages versioned anyhow? > Because newer PPL releases might break gcc. But supposedly this isn't that much of an issue for APRON, hence I'd agree that libapron-dev should build-depend on libppl-dev. Hope this helps, Michael pgpXYf7krycnD.pgp Description: PGP signature
Bug#670571: gcc-4.7 FTBFS on Alpha: gcc multiarch config needs tweak.
Source: gcc-4.7
Version: 4.7.0-4
Severity: Important
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-CC: debian-al...@lists.debian.org
gcc-4.7 FTBFS on Alpha with the following error:
/«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/
-B/usr/alpha-linux-gnu/bin/ -B/usr/alpha-linux-gnu/lib/ -isystem
/usr/alpha-linux-gnu/include -isystem /usr/alpha-linux-gnu/sys-include
-g -O2 -mieee -O2 -g -O2 -mieee -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -mieee -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mieee -I.
-I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/.
-I../../../src/libgcc/../gcc -I../../../src/libgcc/../include
-DHAVE_CC_TLS -o _ashldi3.o -MT _ashldi3.o -MD -MP -MF _ashldi3.dep
-DL_ashldi3 -c ../../../src/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
In file included from /usr/include/stdio.h:28:0,
from ../../../src/libgcc/../gcc/tsystem.h:88,
from ../../../src/libgcc/libgcc2.c:29:
/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such
file or directory
I suggest the following fix:
--- a/src/gcc/config.gcc2012-04-25 19:35:37.0 +1200
+++ b/src/gcc/config.gcc2012-04-26 22:28:42.0 +1200
@@ -767,6 +767,7 @@
case ${target} in
alpha*-*-linux*)
tm_file="${tm_file} alpha/elf.h alpha/linux.h alpha/linux-elf.h
glibc-stdint.h"
+ tmake_file="${tmake_file} alpha/t-linux"
extra_options="${extra_options} alpha/elf.opt"
target_cpu_default="MASK_GAS"
;;
With that my test build of gcc-4.7 has past the previous point of
failure and is in the test suite as I write this.
Thanks,
Michael.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f99a9e1.7090...@orcon.net.nz
Bug#681762: gcc-4.5 FTBFS on alpha: Failed link; work around is to link with --no-relax
Source: gcc-4.5 Version: 4.5.4-1 Severity: important Tags: patch User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-CC: debian-al...@lists.debian.org Justification: Fails to build from source but built in the past. gcc-4.5 FTBFS on alpha with GPREL16 relocation truncation errors in the link of cc1-dummy during stage 1 compilation. Full build log is at: http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.5&arch=alpha&ver=4.5.4-1&stamp=1341297050 The bug is a long standing bug in binutils that occassionally affects linking of very large packages. Unfortunately the use of gcc-4.6 tends to trigger it more often and it is now affecting the build of gcc-4.5. The known work around is to disable relaxation in the linker and the link will then complete successfully. I can manually inject -Wl,--no-relax into the link of cc1-dummy during the stage 1 compilation, rerun "debian/rules build", manually inject -Wl,--no-relax into the link of cc1, rerun "debian/rules build" again, and then the build completes successfully. (My attempts at producing a patch to debian/rules2 to automatically inject the -Wl,--no-relax option into the stage 1 compilation links failed so no patch attached here, sorry.) The old version of gcc-4.5 at debian-ports currently breaks installation of the Alpha port with debootstrap, so an upload of a fix would be very much appreciated, but we will understand if this is not possible because of the freeze. Cheers Michael. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5003de80.3010...@orcon.net.nz
Bug#682197: gnat-4.6 FTBFS on Alpha: Link fails; --no-relax is a workaround.
Source: gnat-4.6 Version: 4.6.3-5 Severity: normal Tags: patch User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-CC: debian-al...@lists.debian.org gnat-4.6 FTBFS on Alpha with GPREL16 relocation truncation errors in the link of gnat1 during stage 1 compilation. Full build log is at: http://buildd.debian-ports.org/status/fetch.php?pkg=gnat-4.6&arch=alpha&ver=4.6.3-5&stamp=1342739232 Adding: ifneq (,$(filter $(DEB_TARGET_ARCH), alpha)) LDFLAGS = -Wl,--no-relax endif to debian/rules2 enables the link to complete successfully. (The bug is actually a long standing bug in binutils that typically only affects the linking of very large C++ projects but seems to be triggered more often now that gcc-4.6 is the default.) I presume adding the above to debian/rules2 will mean that it is also automatically added to the gcc-4.6 and gcj-4.6 packages but that should result in no loss in performance to gcc/g++/gcj/etc since only the link of the stage-1 compiler does not get relaxation optimisation. Cheers Michael. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/500918a2.7020...@orcon.net.nz
Bug#681762: gcc-4.5 FTBFS on alpha: Failed link; work around is to link with --no-relax
On 16/07/12 21:27, Michael Cree wrote: > gcc-4.5 FTBFS on alpha with GPREL16 relocation truncation errors in the > link of cc1-dummy during stage 1 compilation. Full build log is at: Ha, ha, I see I added the patch tag to the bug report but no patch :-/ Adding the following in debian/rules2 enables gcc-4.5 to build on Alpha: ifneq (,$(filter $(DEB_TARGET_ARCH), alpha)) LDFLAGS = -Wl,--no-relax endif Cheers Michael. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/500915c9.2010...@orcon.net.nz
Bug#688278: fails to upgrade/install due to multiarch conflicts
Package: gcc-4.7-base Version: 4.7.2-1 Severity: serious I do have multiarch enabled: amd64 being the primary arch, i386 the secondary. During today's upgrade I got the following error message: Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages will be upgraded: cpp-4.7 g++-4.7 gcc-4.7 gcc-4.7-base:i386 libgcc1 libgcc1:i386 libgfortran3 libgomp1 libitm1 libmission-control-plugins0 libquadmath0 libstdc++6 libstdc++6-4.7-dev telepathy-mission-control-5 14 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 0 B/24.9 MB of archives. After this operation, 108 kB disk space will be freed. Do you want to continue [Y/n]? Retrieving bug reports... Done Parsing Found/Fixed information... Done Reading changelogs... Done Can not write log, openpty() failed (/dev/pts not mounted?) (Reading database ... 249806 files and directories currently installed.) Preparing to replace gcc-4.7-base:i386 4.7.1-9 (using .../gcc-4.7-base_4.7.2-1_i386.deb) ... Unpacking replacement gcc-4.7-base:i386 ... dpkg: error processing /var/cache/apt/archives/gcc-4.7-base_4.7.2-1_i386.deb (--unpack): trying to overwrite shared '/usr/share/doc/gcc-4.7-base/changelog.Debian.gz', which is different from other instances of package gcc-4.7-base:i386 Errors were encountered while processing: /var/cache/apt/archives/gcc-4.7-base_4.7.2-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-30-generic (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120921044421.10905.78738.report...@pluto.milchstrasse.xx
Bug#540083: Is anyone taking care of this package?
> Hi, > > I reported this bug one month ago, including patches. I have been > testing it without problems so far. > > Is anyone taking care of this package? Could the patches be applied to > the package? > Yes, there are people caring about this package. Building the binary packages, however, is a fairly large burden for your buildds, therefore we try to keep the number of uploads low. I will try to see which other patches are supposed to make it into the next upload and try to come up with a new version at the beginning of October (any time sooner is not terribly realistic as I'm loaded with real-life work). Sorry, Michael pgpd0OuJRhBNd.pgp Description: PGP signature
Bug#401948: ecj-bootstrap: The import java.util.Scanner cannot be resolved
reassign 401948 gcj-4.4
close 401948 4.4.0-1
thanks
On Thu, Dec 07, 2006 at 01:21:00AM +0100, Jhair Tocancipa Triana wrote:
> Package: ecj-bootstrap
> Version: 3.2.1-3
> Severity: normal
>
> The following program compiles fine with
>
> /usr/lib/jvm/java-1.5.0-sun/bin/javac
>
> --8<---cut here---start->8---
> import java.util.Scanner;
>
> class TestScanner
> {
> public static void main(String[] args)
> {
> System.out.println ("hi");
> }
> }
> --8<---cut here---end--->8---
>
> But the eclipse compiler says,
>
> (debian-unstable)jtocanc...@golem:~/tmp$ /usr/bin/ecj-bootstrap
> TestScanner.java
> --
> 1. ERROR in TestScanner.java (at line 1)
> import java.util.Scanner;
>^
> The import java.util.Scanner cannot be resolved
> --
>
> The eclipse compiler should be fixed to compile the program.
This is not a bug in the Eclipse compiler itself but in the class library
it uses. When GCJ got updated to version 4.4.0 the Scanner class was
introduced and it now compiles.
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540083: Is anyone taking care of this package?
> Excerpts from Michael Tautschnig's message of Tue Sep 15 16:57:26 +0200 2009: > > Yes, there are people caring about this package. Building the binary > > packages, > > however, is a fairly large burden for your buildds, therefore we try to > > keep the > > number of uploads low. I will try to see which other patches are supposed to > > make it into the next upload and try to come up with a new version at the > > beginning of October (any time sooner is not terribly realistic as I'm > > loaded > > with real-life work). > > At last! :-) > > I will keep an eye on the news about this package. There is no > hurry. I sent another comment because I was afraid the package was > orphaned or something. > > By the way, I am interested in helping with this package. I am > familiar with Debian, although I think that all the > maintainer/developer stuff have slightly changed in the last > months. Anyway, if I can be of help, let me know. > I'm currently trying to build a new package with swi-prolog bindings. If it all works fine, it will sit in NEW queue sometime today or tomorrow. If you want to help, you should probably start with subscribing yourself to the PTS page of the ppl package and just step up once it is time to package the next release. Best, Michael pgpR7KQ9fjAbp.pgp Description: PGP signature
Re: Switch on compiler hardening defaults
> On Monday 26 October 2009 09:22:26 Marco d'Itri wrote: > > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > > uses[2]. > > > > Seconded. > > Thirded. > +1. Thanks for bringing this up, Michael pgpcMDHNXCorM.pgp Description: PGP signature
Bug#552959: ppl: FTBFS: build blocks
Hi! [...] > > if [ . != `pwd` ]; then \ > > rm -f ppl_prolog_generated_test_common.pl; \ > > fi > > rm -f ppl_prolog_generated_test_main.pl; \ > > diff -u --ignore-all-space ./../tests/expected_pgt obtained_pgt > > make[7]: *** [pl_check_test] Terminated > > make[3]: *** [check-recursive] Terminated > > E: Caught signal 'Terminated': terminating immediately > > make[5]: *** [check-recursive] Terminated > > make[4]: *** [check] Terminated > > make[2]: *** [check] Terminated > > make[1]: *** [check-recursive] Terminated > > make: *** [check] Terminated > > make[6]: *** [check-am] Terminated > > Build killed with signal TERM after 240 minutes of inactivity > > > > Build finished at 20091028-0518 > > The full build log is available from: > > http://people.debian.org/~lucas/logs/2009/10/28/ppl_0.10.2-3_lsid64.buildlog > [...] Is it possible to schedule another build? I'm really clueless what could be going wrong here, other than some problem with the buildd, which seems somewhat more likely given the excerpt of daemon.log provided at the end of this log. Looking at other build logs the above diff seems to be about the last thing before install, and it worked fine on all Debian buildds just a few days ago!? Thanks, Michael pgp4e76dmcQcg.pgp Description: PGP signature
Bug#552959: ppl: FTBFS: build blocks
Hi Lucas, Thanks a lot for the quick reply and precise information. [...] > > The fact that it blocks is reproducible. > > Output on the terminal: > % ppl_prolog_generated_test_main.pl compiled 0.18 sec, 2,099,112 bytes > % ./swi_prolog_generated_test compiled 0.18 sec, 2,104,128 bytes > true. > > true. > > > % halt > if [ . != `pwd` ]; then \ > rm -f ppl_prolog_generated_test_common.pl; \ > fi > rm -f ppl_prolog_generated_test_main.pl; \ > diff -u --ignore-all-space ./../tests/expected_pgt obtained_pgt > > > However, it's not diff that is blocking, it's ppl_pl. It's eating all the > available memory and causes swapping. I've attached the output of ps. > the status of the process is: [...] I'll see what I can do about this, I just wonder why it didn't happen on other hosts. But we'll see... Thanks again, Michael pgpYX5eGSn9lk.pgp Description: PGP signature
Bug#552959: Clueless
Hi Lucas, I talked to upstream and was assured that upstream is just as clueless as I am: Both their and my build attempts on amd64 always worked fine, even if making with -jX for some 2 <= X <= 8. Is there any way one could get access to the system you're building these packages, or could you try to dig further yourself? Otherwise I'm absolutely clueless how to handle this. Obviously it fails to build, which is also reproducible on your hosts, but seemingly not in any other environment. I think we'll need some further examinations using strace and gdb at least. Thanks a lot, Michael pgpDfmG0K6AX6.pgp Description: PGP signature
Bug#556790: gcc-4.3: unrecognizable insn on alpha
On 18/11/2009, at 9:31 AM, Kurt Roeckx wrote: Package: gcc-4.3 Version: 4.3.4-5 Hi, I recently started seeing several cases of gcc giving an error message like this: packet-l2tp.c:1680: error: unrecognizable insn: (insn 419 86 84 9 packet-l2tp.c:1585 (set (reg:DI 200) (ne:SI (reg:DI 76 [ prephitmp.1208 ]) (const_int 0 [0x0]))) -1 (nil)) packet-l2tp.c:1680: internal compiler error: in extract_insn, at recog.c:2001 Would this be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113 ?? Cheers Michael. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#556790: gcc-4.3: unrecognizable insn on alpha
On 02/12/09 18:18, Matt Turner wrote: On Tue, Dec 1, 2009 at 3:08 PM, Michael Cree wrote: On 18/11/2009, at 9:31 AM, Kurt Roeckx wrote: Package: gcc-4.3 Version: 4.3.4-5 Hi, I recently started seeing several cases of gcc giving an error message like this: packet-l2tp.c:1680: error: unrecognizable insn: (insn 419 86 84 9 packet-l2tp.c:1585 (set (reg:DI 200) (ne:SI (reg:DI 76 [ prephitmp.1208 ]) (const_int 0 [0x0]))) -1 (nil)) packet-l2tp.c:1680: internal compiler error: in extract_insn, at recog.c:2001 Would this be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113 ?? Hmm. The patch that _uncovered_ (not caused) the regression was http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8603 It was included in>4.3.4 (that is, not in 4.3.4), 4.4.2, and the 4.5 branch, so I don't think it could be 42113, but it certainly couldn't hurt to test. From the Debian gcc-4.3 Changelog: gcc-4.3 (4.3.4-2) unstable; urgency=low [ Aurelien Jarno ] * patches/kbsd-gnu-ada.dpatch: add Ada support on kfreebsd-amd64. * rules.conf: enable Ada on kfreebsd-amd64. [ Matthias Klose ] * Update to SVN 20090826 from the gcc-4_3-branch. - Fixes: PR target/41019, PR target/8603 (closes: #161432), PR rtl-optimization/41033, PR target/40906, PR target/40577, PR fortran/40847, PR fortran/40851, PR c/41046, PR debug/39706. PR middle-end/41094, PR target/40718, PR fortran/41102. * Avoid underscores in doc-base document id's to workaround a dh_installdocs bug. So the patch that uncovered 42113 has been included in Debian's gcc since version 4.3.4-2. Cheers Michael -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#556790: gcc-4.3: unrecognizable insn on alpha
On 06/12/09 23:21, Kurt Roeckx wrote: On Wed, Dec 02, 2009 at 12:18:47AM -0500, Matt Turner wrote: On Tue, Dec 1, 2009 at 3:08 PM, Michael Cree wrote: On 18/11/2009, at 9:31 AM, Kurt Roeckx wrote: Package: gcc-4.3 Version: 4.3.4-5 Hi, I recently started seeing several cases of gcc giving an error message like this: packet-l2tp.c:1680: error: unrecognizable insn: (insn 419 86 84 9 packet-l2tp.c:1585 (set (reg:DI 200) (ne:SI (reg:DI 76 [ prephitmp.1208 ]) (const_int 0 [0x0]))) -1 (nil)) packet-l2tp.c:1680: internal compiler error: in extract_insn, at recog.c:2001 Note that there is a list of packages you could try to reproduce it and a reduced test case in the debian bug tracker. OK, I tested with gcc-4.4 since gcc-4.4.2-3 does not contain the patch for PR/42113, whereas gcc-4.4.2-4 does. Verified that the two debian source packages, libssh2 and mpich2, when compiled with gcc-4.4.2-3 both generate ICEs of the nature shown above. (The reduced test case in the debian bug tracker does not trip the ICE in gcc-4.4.) Compilation with gcc-4.4.2-4 of these two packages is successful (well, I didn't let mpich2 go to completion but it got well past the point where the ICE was generated with gcc-4.4.2-3). So looks like this bug is indeed PR/42113 and is fixed in current unstable gcc-4.4. What is the timeframe for getting the Alpha buildds updated to a fixed version of gcc? Cheers Michael. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565455: gcc-4.4: ICE while compiling fsarchiver 0.6.5-1 on alpha
Package: gcc-4.4 Version: 4.4.2-9 Severity: important Hi, compiling fsarchiver 0.6.5-1 fails on alpha [1] gcc -DHAVE_CONFIG_H -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -I. -I..-g -O2 -Wall -std=gnu99 -rdynamic -ggdb -I/usr/include/ext2fs -I/usr/include/et -lcom_err -I/usr/include/e2p -I/usr/include/blkid -I/usr/include/uuid -I/usr/include/uuid -g -O2 -c -o fsarchiver-fs_ntfs.o `test -f 'fs_ntfs.c' || echo './'`fs_ntfs.c fs_ntfs.c: In function 'ntfs_getinfo': fs_ntfs.c:102: internal compiler error: in get_aligned_mem, at config/alpha/alpha.c:1466 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[3]: *** [fsarchiver-fs_ntfs.o] Error 1 make[3]: Leaving directory `/build/buildd-fsarchiver_0.6.5-1-alpha-4XcaWr/fsarchiver-0.6.5/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd-fsarchiver_0.6.5-1-alpha-4XcaWr/fsarchiver-0.6.5' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd-fsarchiver_0.6.5-1-alpha-4XcaWr/fsarchiver-0.6.5' dh_auto_build: make -j1 returned exit code 2 make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 On all other archs, fsarchiver builds just fine. 0.6.4-1 also built fine on alpha, and the changes between 0.6.4 and 0.6.5 in fs_ntfs.c are minimal. The last upload of fsarchiver-0.6.4-1 has been more than 10 days ago and there was a gcc upload in between which could have caused that regression. Michael [1] https://buildd.debian.org/fetch.cgi?pkg=fsarchiver;ver=0.6.5-1;arch=alpha;stamp=1263529331 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32.3 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gcc-4.4 depends on: ii binutils 2.20-5 The GNU assembler, linker and bina ii cpp-4.4 4.4.2-9The GNU C preprocessor ii gcc-4.4-base 4.4.2-9The GNU Compiler Collection (base ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.2-9 GCC support library ii libgomp1 4.4.2-9GCC OpenMP (GOMP) support library Versions of packages gcc-4.4 recommends: ii libc6-dev 2.10.2-5 Embedded GNU C Library: Developmen Versions of packages gcc-4.4 suggests: pn gcc-4.4-doc(no description available) pn gcc-4.4-locales(no description available) pn gcc-4.4-multilib (no description available) pn libcloog-ppl0 (no description available) pn libgcc1-dbg(no description available) pn libgomp1-dbg (no description available) pn libmudflap0-4.4-dev(no description available) pn libmudflap0-dbg(no description available) pn libppl-c2 (no description available) pn libppl7(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565455: Acknowledgement (gcc-4.4: ICE while compiling fsarchiver 0.6.5-1 on alpha)
severity 565455 normal thanks downgrading to normal as alpha is no longer a release arch and it builds fine on all other architectures. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#570387: prolog tests fail at least on powerpc
> Package: ppl > Version: 0.10.2-4 > Severity: serious > > the prolog tests fail at least on powerpc. Please either fix these > that the package is built again, or ignore the failures in the > prolog testsuite. ppl is used as a gcc build-dependency, and we > shouldn't care that much about clean prolog tests. > I was aware of that and already have a workaround tested and ready for upload; I just did not get around to do the final build. I'll try to get it done as soon as possible. Best, Michael pgpzCdLYns9Ma.pgp Description: PGP signature
Bug#570387: prolog tests fail at least on powerpc
> On 02/19/10 10:32, Michael Tautschnig wrote: > >>Package: ppl > >>Version: 0.10.2-4 > >>Severity: serious > >> > >>the prolog tests fail at least on powerpc. Please either fix these > >>that the package is built again, or ignore the failures in the > >>prolog testsuite. ppl is used as a gcc build-dependency, and we > >>shouldn't care that much about clean prolog tests. > >> > > > >I was aware of that and already have a workaround tested and ready for > >upload; I > >just did not get around to do the final build. I'll try to get it done as > >soon > >as possible. > > Hi Michael, > > is the workaround something that might make sense upstream? > Notice that we have been unable to reproduce the problem. Not really, it merely disables that specific test by commenting it out in the .m4 file. It's reproducible on Debian machines, so it might be tied to that specific version of SWI Prolog. I'll give more details in an email to ppl-devel later on this day. Best, Michael pgp7VXhavgnom.pgp Description: PGP signature
Bug#361608: ecj-bootstrap: takes over /usr/lib/jvm/java-gcj/bin/javac with ../../../../bin/ecj
tag 361608 pending confirmed thanks Hello, this was a bug in java-gcj-compat and got fixed in version 1.0.52-0ubuntu1. I will soon (on monday) upload 1.0.55 to unstable which fixes this too. Thanks for reporting this. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369690: gcc-4.1: FTBFS on hurd-i386: hurd-changes.dpatch needs updating
Package: gcc-4.1 Version: 4.1.0-4 Severity: important Tags: patch Hi, this is the failure: |patching file gcc/ada/adaint.c |Hunk #1 FAILED at 261. |1 out of 1 hunk FAILED -- saving rejects to file gcc/ada/adaint.c.rej this is the second one: |/build/buildd/gcc-4.1-4.1.0/build/./gcc/xgcc |-B/build/buildd/gcc-4.1-4.1.0/build/./gcc/ -B/usr/i486-gnu/bin/ |-B/usr/i486-gnu/lib/ -isystem /usr/i486-gnu/include -isystem |/usr/i486-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libgfortran |-I. -iquote../../../src/libgfortran/io -I../../../src/libgfortran/../gcc |-I../../../src/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE |-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes |-Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -c |../../../src/libgfortran/intrinsics/chdir.c -fPIC -DPIC -o |.libs/chdir.o [...] |../../../src/libgfortran/intrinsics/chdir.c:73: error: |'_gfortran_chdir_i4_sub' aliased to undefined symbol |'_gfortrani_chdir_i4_sub' |../../../src/libgfortran/intrinsics/chdir.c:98: error: |'_gfortran_chdir_i8_sub' aliased to undefined symbol |'_gfortrani_chdir_i8_sub' |make[6]: *** [chdir.lo] Error 1 |make[6]: Leaving directory |`/build/buildd/gcc-4.1-4.1.0/build/i486-gnu/libgfortran' We were finally able to trace back why gfortran-4.1 did not compile anymore, the #pragma weaks are no longer needed as this got fixed in libpthread upstream. Patch attached, I checked it patches fine with that, and Thomas Schwinge made a successful cross-compiled test build. We hope gcc-4.1 is now working for hurd-i386. cheers, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html --- debian/patches/hurd-changes.dpatch.orig 2006-05-31 14:43:11.0 +0200 +++ debian/patches/hurd-changes.dpatch 2006-05-31 14:45:15.0 +0200 @@ -27,8 +27,6 @@ # DP: upstream. # DP: # DP: Define MAXPATHLEN and PATH_MAX. -# DP: -# DP: Add some #pragma weak for _pthread_* functions. --- gcc/config/gnu.h.orig 2005-06-22 13:23:24.0 +0200 +++ gcc/config/gnu.h 2005-06-22 13:24:18.0 +0200 @@ -62,25 +60,9 @@ /* Defined in the automatically-generated underscore.c. */ extern int prepends_underscore; gcc/gthr-posix.h.orig 2005-07-19 13:58:06.0 +0200 -+++ gcc/gthr-posix.h 2005-07-23 17:28:14.0 +0200 -@@ -40,6 +40,13 @@ - #define _REENTRANT 1 - #endif - -+#pragma weak _pthread_mutex_lock -+#pragma weak _pthread_mutex_trylock -+#pragma weak _pthread_mutex_unlock -+ -+#pragma weak _pthread_mutex_init -+#pragma weak _pthread_mutex_destroy -+ - #include - #include - gcc/ada/adaint.c.orig 2005-08-01 23:10:02.0 +0200 -+++ gcc/ada/adaint.c 2005-08-01 23:11:10.0 +0200 -@@ -261,6 +261,10 @@ +--- gcc/ada/adaint.c.orig 2006-05-29 17:43:55.0 +0200 gcc/ada/adaint.c2006-05-29 17:54:32.0 +0200 +@@ -272,6 +272,10 @@ #include #endif @@ -88,6 +70,6 @@ +#define MAXPATHLEN 4096 +#endif + + #ifdef MAXPATHLEN #define GNAT_MAX_PATH_LEN MAXPATHLEN - - #endif + #else
Re: bits from the release team: release goals, python, X.org, amd64, timeline
> On Tue, May 30, 2006 at 02:01:19PM -0700, Steve Langasek wrote: > > BTW, can you tell me anything about the dip in > > http://buildd.debian.org/stats/graph2-quarter-big.png for m68k? Seems to be > > heading in the wrong direction again for being a release candidate. I see > > 12 buildds actively uploading packages for m68k, is this too few or is there > > some other problem? > > Personally, I'm not sure what the problem is, actually. Anyone else? For my part, it's due to the third version of glibc being built in as many days (one on crest, two on hobbes) each blocking a fast host for 48+ hours, IIRC. Unless there's other biggies lurking in the queue, we should catch up once the hopfully final glibc build is through. N.B.: the flurry of glibc uploads speaks loud and clear as to people getting their packages into shape for release. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team: release goals, python, X.org, amd64, timeline
> Since m68k pretty much depends on the gcc-4.1 transition to make it in > again, I would suggest that we (as in, the m68k port) make the switch to > GCC4.1 as the default already. This will allow us to verify that stuff > actually builds and works, and to catch up with building those that fail > with ICE in gcc-4.0 before that time. Since m68k is not a release > architecture right now, this should not cause any problems for any other > port if the GCC 4.1 transition does not happen, but it will help if it > does. > > Thoughts, objections? I fully concur. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
