Bug#430049: gcc-4.1: acovea triggers error in gcc

severity 430049 normal tags 430049 needsinfo thanks Folkert van Heusden writes: > Severity: grave > Justification: renders package unusable no. works ok for nearly all other debian packages; please don't misuse severities for bug reports. > population 1: cc1: warning: -f[no-]force-mem is no

Processed (with 1 errors): Re: Bug#430049: gcc-4.1: acovea triggers error in gcc

Processing commands for [EMAIL PROTECTED]: > severity 430049 normal Bug#430049: gcc-4.1: acovea triggers error in gcc Severity set to `normal' from `grave' > tags 430049 needsinfo Unknown tag/s: needsinfo. Recognized are: patch wontfix moreinfo unreproducible fixed potato woody sid help security

Bug#430049: gcc-4.1: acovea triggers error in gcc

Package: gcc-4.1 Version: 4.1.2-6 Severity: grave Justification: renders package unusable While running acovea to determine optimal compilationflags, a bug gets triggered: [EMAIL PROTECTED]:~/Personal/src/multitail/devel$ runacovea -config /usr/share/libacovea/config/gcc41_opteron_nofm.acovea -

Bug#430013: gcc-snapshot FTBFS on mips (and presumably also on mipsel)

Package: gcc-snapshot Version: 20070613-1 Severity: important Gcc-snapshot FTBFS on mips, and is likely to fail with the same problem on mipsel: [...] /srv/ths/debian/gcc-snapshot/gcc-snapshot-20070613/build/./gcc/xgcc -B/srv/ths/debian/gcc-snapshot/gcc-snapshot-20070613/build/./gcc/ -B/usr/lib

Why does gcc-4.2 build-depend on lib32z-dev?

I'm wondering why the multiarch build dependencies include lib32z-dev or lib63z-dev; is this specific to some language, or does this apply to all languages? I suspect this is only useful for Java. Line 169 in rules.conf says: LIBC_BIARCH_BUILD_DEP = [...] lib64z1-dev [i386 powerpc sparc s390], li

GNU C++ problem

Hello I have a package that was built with g++-4.1_4.1.1-21 for amd64 ocp 0.1.11-1 that links against a library built with g++-4.0_4.0.3-1 for amd64 libsidplay 1.36.59-4. This is a problem when using that library, the software crashes. You can simply reproduce this the following way on etch:

Bug#429947: libstdc++6: breaks dchroot: E: locale::facet::_S_create_c_locale name not valid

Package: libstdc++6 Version: 4.2-20070609-1 Severity: normal Version 4.2-20070609-1 breaks 'dchroot' (and probably 'schroot' as well): leszek> dchroot E: locale::facet::_S_create_c_locale name not valid Downgrading to 4.2-20070528-1 solves the problem. Also, running dchroot like this leszek

Processed: Forwarded upstream

Processing commands for [EMAIL PROTECTED]: > forwarded 429934 http://gcc.gnu.org/PR32452 Bug#429934: gnat-4.1: Incorrect type debugging information for variables in other compilation units Noted your statement that Bug has been forwarded to http://gcc.gnu.org/PR32452. > thanks Stopping processin

Bug#429934: gnat-4.1: Incorrect type debugging information for variables in other compilation units

Package: gnat-4.1 Version: 4.1.1-22 Severity: normal Tags: confirmed, upstream In the test case below, GCC emits correct type information for Debugging.A but the type information for Extenal.B is incorrect. package External is type External_Type is array (1 .. 4) of Float; B : External_Type