Bug#191008: hurd-i386 should use /usr/include, not /include

Package: gcc-3.2 Severity: normal Tags: patch Traditional GNU systems don't have a /usr directory. However, Debian systems do, and we support both having a /usr -> . symlink, and having a /usr directory like the other ports. So this patch should NOT go upstream. --- gcc/config/t-gnu.old

Results for 3.2.3 testsuite on s390-ibm-linux-gnu

LAST_UPDATED: Native configuration is s390-ibm-linux-gnu === g++ tests === Running target unix WARNING: program timed out. FAIL: g++.benjamin/15800-2.C (test for excess errors) FAIL: g++.eh/terminate2.C Execution test XPASS: g++.other/init5.C Execution test ==

Results for 3.2.3 testsuite on sparc-unknown-linux-gnu

LAST_UPDATED: Native configuration is sparc-unknown-linux-gnu === g++ tests === Running target unix FAIL: g++.law/profile1.C Execution test XPASS: g++.other/init5.C Execution test === g++ Summary === # of expected passes7352 # of unexpected failur

Results for 3.2.3 testsuite on powerpc-unknown-linux-gnu

LAST_UPDATED: Native configuration is powerpc-unknown-linux-gnu === g++ tests === Running target unix XPASS: g++.other/init5.C Execution test === g++ Summary === # of expected passes7349 # of unexpected successes 1 # of expected failures

Results for 3.2.3 testsuite on alpha-unknown-linux-gnu

LAST_UPDATED: Native configuration is alpha-unknown-linux-gnu === libjava tests === Running target unix FAIL: StringBuffer_1 execution from source compiled test FAIL: StringBuffer_1 execution from bytecode->native test FAIL: StringBuffer_1 -O execution from source compiled test

Results for 3.2.3 testsuite on ia64-unknown-linux-gnu

LAST_UPDATED: Native configuration is ia64-unknown-linux-gnu === g++ tests === Running target unix XPASS: g++.other/init5.C Execution test FAIL: g++.pt/repo3.C (test for excess errors) === g++ Summary === # of expected passes7186 # of unexpected fa

Bug#188976:

Felix Havemann writes: > This is a serious bug and apparently nobody want's to fix > it. If I'd be able to do so I would, but I'm not. change the lib64 definition in debian/rules.defs, build the package, test the upgrade procedure, make sure you don't break other architectures and report the resu

Bug#190964: gcc-3.2: No .mo files included in the package?

Ole Laursen writes: > Package: gcc-3.2 > Version: 1:3.2.3-0pre9 > Severity: normal > > Some people have spent quite a lot of time translating GCC messages > into other languages (yeah, I happen to be one of them). But these > translation .mo files don't seem to be included in any of the Debian > p

g++ 3.3 mixes up types when an initialized field in a union is not the first one

>Submitter-Id: net >Originator:Andreas Oberritter >Organization: >Confidential: no >Synopsis: g++ 3.3 mixes up types when an initialized field in a union is not the first one >Severity: serious >Priority: medium >Category: c++ >Class: rejects-legal >Release:

Bug#190964: gcc-3.2: No .mo files included in the package?

Package: gcc-3.2 Version: 1:3.2.3-0pre9 Severity: normal Some people have spent quite a lot of time translating GCC messages into other languages (yeah, I happen to be one of them). But these translation .mo files don't seem to be included in any of the Debian packages. I don't know if that is a

Bug#188976:

Hi Ray, On Sonntag, April 27, 2003, at 11:41 Uhr, J.H.M. Dassen (Ray) wrote: On Tue, Apr 22, 2003 at 14:08:19 -0400, Matt Zimmerman wrote: This looks like a genuine bug. I concur. ;-) This raises the question why to use debian on a sparc system in the first place. This is a serious bug and appar

you must be worried 524vu42gpj8b

Erase your email record here.

Bug#188976:

On Tue, Apr 22, 2003 at 14:08:19 -0400, Matt Zimmerman wrote: > This looks like a genuine bug. I concur. > So /lib/64 is a symlink in libc6-sparc64, but a directory in libgcc1. libgcc1 should be changed to install in /lib64 rather than /lib/64 . On Sat, Apr 26, 2003 at 09:19:48 +0200, Martin v.