ice with gcc 3.1 when optimizing for k6

>Submitter-Id: net >Originator: Peter Cordes >Confidential: no >Synopsis: ice with gcc 3.1 when optimizing for k6 >Severity: serious >Priority: medium >Category: target >Class: ice-on-legal-code >Release: 3.1.1 20020606 (Debian

bye bye big thighs

Body Wrap at Home to lose 6-20 inches in one hour. With Bodywrap we guarantee: you'll lose 6-8 Inches in one hour 100% Satisfaction or your money back Bodywrap is soothing formula that contours, cleanses and rejuvenates your body while reducing inches. http://artemisia.grouploseweig

Bug#96539: libstdc++2.10-dev: Error in bastring.h

Package: libstdc++2.10-dev Version: 1:2.95.2-14 Severity: important In bastring.h: const charT* c_str () const { const charT* null_str = ""; if (length () == 0) return null_str; terminate (); return data (); } The second line will _fail_ if charT is not char, which it for instance i

Complaints from gcc.

The log from a compilation is at https://easthope.ca/makeLog . To provide absent functions I should install additional packages? Function names should be aliased? I need to change the utelnetd.c to work in Debian? Otherwise? Thanks, ... P. -- VoIP: +1 604 670 0140 work: https

Bug#840694: gcc: /usr/bin/gcc should use /etc/alternatives

c and its friends are direct symlinks to /usr/bin/gcc-6 By `friends' I mean cpp, c++, c89 c99 gcc-ar gcc-ranlib gcc-nm etc. The same goes for the various cross compilers (arm-linux-gnueabi-gcc etc) -- Dr Peter Chubb Tel: +61 2 9490 5852 http://ts.data61.csiro.au/ Trustwort

Bug#945886: creduce: build-depends on package that is not in testing.

Package: creduce Version: 2.10.0-2 Severity: serious creduce build-depends on frama-c-base which is built by the frama-c source package which is not currently in testing. Either frama-c needs to be fixed to get it back in testing, creduce needs to eliminate the dependency (no idea if this is p

Bug#1049367: elfutils: [INTL:sv] Swedish translation of debconf messages

Package: elfutils Version: 0.189-4 Severity: wishlist Tags: l10n patch X-Debbugs-Cc: peterkvilleg...@posteo.net Dear Maintainer, Please copy the attachment into debian/po/sv.po It has been reviewed by the Swedish translation team, tested with msgfmt, and is in UTF-8. Regards, Peter Kvillegård

gcc-8, libatomic and armel/raspbian

It seems that gcc-8 unconditionally builds parts of libatomic with "-march=armv7-a+fp". This was detected by Raspbian's armv7 contamination checker before the package was uploaded to raspbian. There is no such checking for Debian armel so the package was accepted there and is now being shipped

Bug#999904: Uncoordinated split of debugedit package out of src:rpm

filing this bug for the purpose of keeping the new version of debugedit out of testing for the present. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115

Bug#999904: Uncoordinated split of debugedit package out of src:rpm

Version: 4.17.0+dfsg1-1 On Thu, Nov 18, 2021 at 12:19:10PM +0200, Peter Pentchev wrote: > control: tag -1 + confirmed pending > > On Thu, Nov 18, 2021 at 09:45:06AM +0100, Laurent Bigonville wrote: > > Source: debugedit,rpm > > Severity: serious > > Tags:

Bug#151065: g++: destructor called twice

Package: g++ Version: 2:2.95.4-14 Severity: normal Hi ! We have problems with a C++ program reported in detail below. It is not a Debian specific problem. In particular we checked: - there is the same problem using GNU C++ compiler on SuSE Linux and MacOS X - Code compiles and executes properly

Bug#180218: gcj-3.2 should provide javah alternative

-wrapper already in the package. Could you please add this to the package as gcjh-wrapper and add a link to it from /usr/bin/javah through the alternatives system? I will send the file as an attachment to a follow up for this bug report, since I'm not sure [EMAIL PROTECTED] likes attachments. =) Peter

Bug#180218: javah script

Attached. #!/usr/bin/perl -w # # Starts the GNU Java header generator. # # Command-line arguments should be in the style of Sun's javah command; # these will be converted to gcjh arguments before being passed to the # gcjh itself. # # Copyright (C) 2003 by Peter Hawkins <[EMAIL P

Bug#448480: GCC miscompilation on ARM

Package: gcc Version: 4:4.1.1-15 GCC miscompiles the following code :- extern void extfunc(void); extern unsigned extvar; static void inner(char *a, unsigned b) { if (b) extfunc(); else extvar = (unsigned) a; } void outer(unsigned a, unsigned b)

Bug#448480: I've just realised that ...

... the assignment of the address of a local variable to a global variable looks a bit odd, but in the original code that exhibited the failure this assignment was to a constant address thus *(volatile unsigned *) DMA_ADDR_REG = (unsigned) a; which is valid. -- To UNSUBSCRIBE, email

Bug#486347: gcc-4.3: Superfluous warning when -std=c99/gnu99 and noreturn on main()

precision arithmetic library ii libmpfr1ldbl 2.3.1.dfsg.1-2 multiple precision floating-point Thanks for your time, Peter Lebbing. - -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (100, 'unstable') Architecture

Bug#486347: gcc-4.3: Superfluous warning when -std=c99/gnu99 and noreturn on main()

ing, > it will always call strlen() at run-time. Doesn't sound like what I want. Thanks for the reply, Peter. -- I'm using the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.e

re: plink FTBFS: #error "Cannot determine endianness.

tags 528659 +patch thanks It seems that gcc on debian doesn't define __{BIG|LITTLE}_ENDIAN__ or any of the equvilents the package checks for. The package has hardcoded fallbacks for some architectures but not others hence the FTBFS on some but not all debian architectures (roughly correlated w

Bug#617968: libstdc++6-4.5-dev: Apps that include FTBFS

After much trial and erorr I managed to reduce the problem to the attatched trivial example. I do not know enough C++ to say if this is supposed to work or not but I can say it builds with 4.4 but not 4.5. Note: i'm just doing flyby RC bug investigation (yes I know this bug is marked as import

Bug#670821: gcc-4.6: build system treats systems that identify themselves as wheezy differently from systems that identify themselves as sid

Package: gcc-4.6 Version: 4.6.3-1 Severity: important Tags: patch While working on an unofficial "hardfloat for pi" port of debian I discovered that building the gcc-4.6 package in an environment that identifies itself (though lsb-release) as wheezy results in the build choosing different opti

gcc-4.6 gcc-defaults, gcc-mingw and wheezy

gcc-defaults in testing depends on gccgo-4.6 which is no longer built by the gcc-4.6 source package in unstable. The new gcc-defaults in unstable is blocked from migrating due to the standoff between the release team and the gcc maintainers over gcc-4.7. As a result of this gcc-4.6 cannot migra

Bug#570838: g++-4.4: Wrong "value computed is not used" warning, when the subexpression has a leftvalue.

s for your voluntary efforts, Peter PROHLE. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-19

Bug#570838: lower the severity

is not used. 1: I suggest to lower the severity of this report #570838 2: I suggest to enhance the the warning string of the compiler to something like this: "value of the non-last member of the comma expression is not used" Regards, Peter PROHLE. -- To UNSUBSCRIBE, em

Bug#570838: missing warning, false error

at the location in question is affected by the presence and the position of the operator ++. But the both of ++j and j++ have a left value identical to the left value of j, not? I have cheked, that omitting the parenthesis does not help. Regards, Peter PROHLE. -- To UNSUBSCRIBE, emai

Bug#553045: Same bug on IA64

4gomp1-i386-cross/DEBIAN/shlibs.fixed /bin/bash: debian/lib64gomp1-i386-cross/DEBIAN/shlibs: No such file or directory make[1]: *** [stamps/08-binary-stamp-lib64gomp] Error 1 make[1]: Leaving directory `/usr/src/toolchain/gcc-4.4-4.4.3' make: *** [binary] Error 2 -- Dr Peter Chubbwww.n

Bug#367038: every upload of gcc breaks links in include directory

Package: java-gcj-compat Version: 1.0.30-4 Severity: important This package supplies: $ ls -l /usr/lib/jvm/java-gcj/include/ total 4 lrwxrwxrwx 1 root root 45 Mar 29 12:23 gcj -> ../../../gcc/i486-linux-gnu/4.0.2/include/gcj lrwxrwxrwx 1 root root 48 Mar 29 12:23 jawt.h -> ../../../gcc/i486

Bug#367435: lib32gcc1: Will not install: conflicts with libgcc1

Package: lib32gcc1 Version: 1:4.0.2-9+ia32.libs.1.6 Severity: normal When I try to install lib32gcc1, I see: Preparing to replace lib32gcc1 1:3.4.3-12+ia32.libs.1.5 (using .../lib32gcc1_1%3a4.0.2-9+ia32.libs.1.6_ia64.deb) ... Unpacking replacement lib32gcc1 ... dpkg: error processing /var/cache

Bug#368967: libgcj6-dev: placing jni.h in versioned subdirectory makes no sense

Package: libgcj6-dev Version: 4.0.2-5j2 Severity: normal This package installs jni.h in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/. This only works if you happen to use gcc 4.0.3 to compile the C program you're dealing with, but my gcc thinks it's version 4.0.4: $ gcc -print-search-dirs install:

Bug#365934: java-gcj-compat-dev: Dead links in /usr/lib/jvm/java-gcj/include/

reopen 365934 stop If you choose to resolve this by tightening the dependency on gcj, then the dependency needs to look something like gcj-4.1 (>= 4.1.1), gcj-4.1 (<< 4.1.2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#365934: java-gcj-compat-dev: Dead links in /usr/lib/jvm/java-gcj/include/

Am Donnerstag, 1. Juni 2006 16:58 schrieb Matthias Klose: > Peter Eisentraut writes: > > reopen 365934 > > stop > > > > If you choose to resolve this by tightening the dependency on gcj, then > > the dependency needs to look something like > > > > gcj

Bug#368967: libgcj6-dev: placing jni.h in versioned subdirectory makes no sense

severity 368967 grave stop I have to raise the severity of this because most gcj-using packages are currently unbuildable as a result of this. Examples are libgnujaxp-java and postgresql-pljava. #365934 in java-gcj-compat-dev is a related issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]

Bug#370518: placing jni.h in versioned subdirectory makes no sense

Package: libgcj7-dev Version: 4.1.0-2j1 Severity: grave This package installs jni.h in /usr/lib/gcc/i486-linux-gnu/4.1.1/include/. This only works if you happen to use gcc 4.1.1 to compile the C program you're dealing with, but my gcc thinks it's version 4.0.4: $ gcc -print-search-dirs install: /

Bug#385732: downgrade severity?

Can this bug's title be changed to "Source package contains useless files", and accordingly its severity be reduced to minor or wishlist ? pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#391410: guifrications ftbfs on powerpc buildd because of problem installing gij

package: gij-4.1 severity: grave the buildd log in question is at http://buildd.debian.org/fetch.php?&pkg=guifications&ver=2.13%7Ebeta3-0.1&ar ch=powerpc&stamp=1159970889&file=log&as=raw, the following is an extract from that log Setting up gij-4.1 (4.1.1-15) ... gcj-dbtool-4.1: error while loadi

Bug#391410: guifrications ftbfs on powerpc buildd because of problem installing gij

> This one time, at band camp, peter green said: > > i belive the soloution is to make gij-4.1 pre-depend on libgcj7-0 > Surely a simple Depends should do the trick? according to http://packages.debian.org/unstable/devel/gij-4.1 a depends is already there. i thought pre-depends w

Bug#391410: guifrications ftbfs on powerpc buildd because of problem installing gij

> a buildd problem, not a package problem; will be fixed tonight. has this been fixed and if so has the guifrications build been requeued? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#630697: gcc-4.4: atom cpu optimization is not supported (-march,-mtune reject atom)

Package: gcc-4.4 Version: 4.4.5-8 Severity: important I tried to compile a "hello, world!" program with 'gcc -march=atom hello.c' and received the following output: hello.c:1: error: bad value (atom) for -march= switch hello.c:1: error: bad value (atom) for -mtune= switch -- System Information:

Re: Bug#623263: shibboleth-sp2: FTBFS on armel (ICE)

If there is a need to get this package building on armel again before the gcc bug is fixed it is possible to do so by building it with g++-4.4 (4.5 and 4.6 both fail) on armel. I've attatched a patch that does that. Thanks for the patch! Do you know if this will cause any problems given

Re: Increasing minimum 'i386' processor

[Goswin von Brederlow] > Where the relevant patches added to binutils and gcc for this? See for yourself: http://sites.google.com/site/x32abi/ -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject

Bug#652205: assembler errors when trying to build flint on armhf

package: gcc-4.6 severity: important version: 1.011-2 flint FTBFS on armhf with the following errors gcc -fPIC -std=c99 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -funroll-loops -I/usr/include -I/usr/include/NTL -c ZmodF.c -o Zmo

gnat in debian armhf

It seems ubuntu armhf already has gnat-4.6 but it's blocked from autobuilding in debian due to a depency loop (gnat-4.6 build-depends on gnat which depends on gnat-4.6). Can someone get this bootstrapped so libreoffice can build*? * libreoffice build-depends on mingw-w64 which is uninstallable

Bug#656739: Old gdc binaries blocking testing migration of gcc-defaults

Package: gcc-defaults severity: important version: 1.111 gcc-defaults recently switched the default gdc to gdc-4.6 and in the process dropped the gdc binary package on architectures that don't have gdc-4.6 (armel, ia64, mips, mipsel, powerpc, s390, sparc, armhf and s390x). This is blocking the

Bug#657682: gcc-4.6: assembler error on armhf Error: can't resolve `.rodata' {.rodata section} - `.LPIC10' {*UND* section}

Package: gcc-4.6 Version: 4.6.2-12 Severity: important Gmime failed to build on armhf with the following error libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../util -DGMIME_VERSION=\"2.4.31\" -DGMIME_MAJOR_VERSION=2 -DGMIME_MINOR_VERSION=4 -DGMIME_MICRO_VERSION=31 -DG_LOG_DOMAIN=\"gmim

Bug#657682: gcc-4.6: assembler error on armhf Error: can't resolve `.rodata' {.rodata section} - `.LPIC10' {*UND* section}

I have reduced this to the attatched testcase sorry, screwed up trying to attatch the file in reportbug, here's the testcase. /* -*- Mode: C; tab-width: 8; indent-tabs-mode: t; c-basic-offset: 8 -*- */ /* GMime * Copyright (C) 2000-2010 Jeffrey Stedfast * * This library is free software;

libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

Libreoffice hasn't yet been built on armhf. I consider libreoffice to be a reasonablly important package and one that we need to get in before we can claim we have a reasonablly complete port. The reason libreoffice isn't built is because mingw-w64 is not installable. The reason mingw-w64 is no

Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

Rene Engelhard wrote: Hi, Libreoffice hasn't yet been built on armhf. I consider libreoffice to be a reasonablly important package and one that we need to get in before we can claim we have a reasonablly complete port. And the segfault described on https://bugs.launchpad.net/ubuntu/

Bug#659793: gcc-4.6: ICE on sparc while building audacious

Package: gcc-4.6 Version: 4.6.2-14 Severity: important Attempting to build the attatched file (preprocessed output from a file that forms part of audacious) with the following command gcc -fPIC -DPIC -g -O2 -std=gnu99 -pipe -pthread -c -xcpp-output ui_fileopener.preprocessed produces root@net

Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

Luke Kenneth Casson Leighton wrote: i686-w64-mingw32-g++ is called. that's different from mingw-w64, then. No it's *part of* mingw-w64. Mnigw-w64 is a fork of mingw32 and provides toolchains targetting both 32-bit and 64-bit windows. These toolchains (at least in debian, not sure a

Bug#659793: gcc-4.6: ICE on sparc while building audacious

forwarded 659793 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52425 thanks Matthias Klose wrote: tags 659793 + moreinfo help thanks does it work with 4.5, 4.7 (snapshot)? Works with both 4.5 and snapshot, only 4.6 seems to suffer the problem. please forward it upstream after investigating. Do

Bug#661868: gcc-4.6 -combine fails

Package: gcc-4.6 Version: 4.6.2-16 Severity: normal Dear Maintainer, gcc-4.4 and earlier had an option '-combine' that conflated all the C files given to it as a single unit to allow inter-procedural optimisation. gcc-4.6 doesn't seem to have this option, but I can't find anyt

Bug#657682: gcc-4.6: assembler error on armhf Error: can't resolve `.rodata' {.rodata section} - `.LPIC10' {*UND* section}

Version: 4.6.2-15 Both gmime and gmime2.4 have now been built sucessfully (one on the buildd the other on a porterbox). I am therefore closing this bug (versioned with the version that built gmime successfully. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject

Obtain a College Degree, fast and easy.

University Degrees and Diplomas Get a Bachelors, Masters, MBA, or Doctorate (PhD) We are able to send your certificate to all countries (WORLDWIDE) Consider a more prosperous future with more money earning power! No testing, studying, or interviews required. Discreet and affordable. Everyone

Bug#335650: gij-4.0: assertion failure with rhdb-explain

Package: gij-4.0 Version: 4.0.2-2 Severity: normal The package rhdb-explain currently requires a Sun JDK. Trying it with gij leads to this: gij -cp /usr/share/java/postgresql.jar:/usr/share/java/rhdb-explain.jar com.redhat.rhdb.vise.Vise ** ERROR **: file ../../../src/libjava/jni/gtk-peer/gnu

Bug#341331: FTBFS for cross compilation

Package: gcc-3.4 Version: 3.4.4-9 When trying to build an IA64 cross-compiler from the gcc-3.4 source package on AMD64, I get, during the packaging stage... $ GCC_TARGET=ia64 fakeroot debian/rules binary ... dh_installdeb -plibstdc++6-ia64-cross dh_md5sums -plibstdc++6-ia64-cross dh_builddeb -p

Bug#343313: libstdc++6: upgrade breaks existing applications with scim 1.0.2-3

Package: libstdc++6 Version: 4.0.2-5 Severity: important Upgrading libstdc++6 from 4.0.2-2 to 4.0.2-5 causes crashes in various gtk programs when GTK_IM_MODULE=scim is in the environment. I have the following scim-related packages: ii scim 1.0.2-3Smart Common Input Me

Bug#343313: libstdc++6: upgrade breaks existing applications with scim 1.0.2-3

[I haven't cc'd debian-release@lists.debian.org or [EMAIL PROTECTED] On Wed, Dec 14, 2005 at 12:48:50PM +0100, Matthias Klose wrote: > I think it's wrong to add conflicts to libstdc++6. we'll end up with > an unmanagable long list of conflicts. can the conflict be added to > some basic gtk package

Bug#343313: see also #343060

Bug #343060 requests a rebuild of the aspell packages, and I've added some information there. The aspell maintainer points out that the backtrace for the crash I get has one of scim's rather than libaspell's functions as the caller of the delete that causes the double-free crash, which (combined w

Please assign back to libgcj-common: missing symlink handling

reassign 396583 libgcj-common thanks Brendan O'Dea's message of 3 Nov 2006 to #396583 indicates a failure of libgcj-common's control scripts to clean up a symlink created by a previous version (apparently libgcj-common 1:4.1.0-2j1, see below). The result is that /usr/share/doc/$P/{changelog.Debi

FW: RE gcc plans for the lenny cycle

>Next GCC 4.2 will be prepared to be included in unstable; a current >issue is http://sourceware.org/bugzilla/show_bug.cgi?id=4302 which has >to be resolved before g++-4.2 can enter unstable. That bug is marked as "resolved invalid" with a reply "Those symbols are for glibc. Why do they have libstd

Re: FW: RE gcc plans for the lenny cycle

>So? Does that mean the bug doesn't affect GCC 4.1? In that case, I >believe Peter is correct that the bug must be resolved before GCC 4.2 >can enter unstable. Do you agree? That wasn't text i wrote it was text i was quoting. I was just asking if anyone knew if there was

Bug#422971: gcc-4.1: FTBFS on arm: Error: junk at end of line,

shouldn't this copy be closed as well.

Bug#423740: Processed: Re: Bug#423740: postgresql-pljava: FTBFS: gcjh: Command not found

Am Montag, 14. Mai 2007 10:28 schrieb Matthias Klose: > please use gjavah, gcjh is obsolete. Where is this documented? Why is there no transition plan? Why does gcjh-4.1 still exist? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTEC

Bug#425011: gcc-4.1: FTBFS on m68k and arm, multiple definitions of ffi_prep_closure

package:gcc-4.1 version:4.1.2-7 severity:serious from the relavent buildd logs: /bin/sh ./libtool --mode=link /build/buildd/gcc-4.1-4.1.2/build/./gcc/xgcc -B/build/buildd/gcc-4.1-4.1.2/build/./gcc/ -B/usr/arm-linux-gnu/bin/ -B/usr/arm-linux-gnu/lib/ -isystem /usr/arm-linux-gnu/include -isystem /u

Bug#425011: gcc-4.1: FTBFS on m68k and arm, multiple definitions of ffi_prep_closure

> This type of message does not give me a warm and fuzzy feeling > that makes me > want to work on the Debian arm port. I'd just like to point out that you are addressing your critisism at the wrong person. your reply seems to be directed at a message from a person replying to me not to me.

RE: Processed (with 1 errors): reopen, retitle and downgrade

> did you have a look at Aurelian's patch and really check this before > reopening the report? the last patch in the bug report only touches an arm specific file so i don't see how it can change the fail/non fail status on m68k. The changelog of the package doesn't say anything about m68k either.

Bug#764732: gcc-4.9: broken -O2 optimizations on armhf

Matthias Klose wrote: there exist several workarounds for it (lowering the optimization, using gcc-4.8, ...). Disabling stack protector also seems to result in a succesful compile (reducing it from strong to regular does not). -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org w

Bug#764732: gcc-4.9: broken -O2 optimizations on armhf

peter green wrote: Matthias Klose wrote: there exist several workarounds for it (lowering the optimization, using gcc-4.8, ...). Disabling stack protector also seems to result in a succesful compile (reducing it from strong to regular does not). And another workaround is to use -marm

Bug#796246: ICT Service Desk

ICT Service Desk require you to upgrade to the latest e-mail Outlook Web Apps 2015 , kindly Click on ICT Service Desk to upgrade to the latest e-mail Outlook Web Apps 2015 Connected with Microsoft Exchange © 2015 Microsoft Corporation. All rights reserved

On compiler defaults and derivatives.

There are derivatives of debian that change compiler defaults (for example minimum CPU requirements). Two such derivatives are raspbian and ubuntu. First lets look at how those derivatives currently handle things. Ubuntu The ubuntu approach is to include the ubuntu specific stuff in the debia

Packaging GCC plugin

suggestions or guidelines for packaging GCC plugins? It would be sufficient to have one version of the binary package of the plugin, which depends on the GCC version provided by gcc-defaults. Thanks, Peter -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubs

Bug#697805: gcc-4.(7|8) FTBFS on non-ubuntu based derivatives that change output of lsb_release -is (was: gcc-4.7 fails to build with dpkg-buildpackage)

reopen 697805 retitle 697805 gcc-4.(7|8) FTBFS on non-ubuntu based derivatives that change output of lsb_release -is severity 697805 normal thanks I just ran into this issue while updating gcc in raspbian. It is a real bug IMO but it is more subtule than the original submitter realised. I ha

Bug#697805: gcc-4.(7|8) FTBFS on non-ubuntu based derivatives that change output of lsb_release -is

8.2-1+plugwash1) unreleased; urgency=low + + * Use $(derivative) instead of $(distribution) to distinguish between Debian +and Ubuntu so Debian derivatives get the Debian settings and Ubuntu +derivatives get the Ubuntu settings. + * Add conditionalised defaults for Raspbian. + + -- Pete

Bug#731891: gcc-4.4 FTBFS on mips* with 3.8 kernel headers

Package: gcc-4.4 Severity: serious Tags: jessie, sid In file included from ../../../../src/libgcc/../gcc/unwind-dw2.c:333: ../../../../src/libgcc/../gcc/config/mips/linux-unwind.h: In function 'mips_fallback_frame_state': ../../../../src/libgcc/../gcc/config/mips/linux-unwind.h:78: error: field

Bug#731891: gcc-4.4 FTBFS on mips* with 3.8 kernel headers

) unstable; urgency=medium + + * Non-maintainer upload. + * Fix build with linux 3.8 headers on mips*. Closes: #731891 + + -- Peter Michael Green Wed, 11 Dec 2013 01:18:00 + + gcc-4.4 (4.4.7-5) unstable; urgency=low * Stop building mudflap packages. diff -u gcc-4.4-4.4.7/debian/patches

Bug#713126: gcj-4.6: FTBFS: unsatisfiable build-dependency: automake (< 1:1.12) but 1:1.13.3-1 is to be installed

so it doesn't hit the virtual +package now provided by binutils. + * Remove freetype/ from freetype includes as the files have moved. + + -- Peter Michael Green Sat, 21 Dec 2013 01:02:36 + + gcj-4.6 (4.6.4-2) unstable; urgency=low * Sync packaging and updates with gcc-

Bug#820831: gcc miscompiling memcpy

Package: gcc Version: 4:4.9.2-2 I am observing what appears to be gcc miscompiling a memcpy call. In the following transcript, note that the memcpy call should be writing to the memory range [0x9ca17df, 0x9ca17e7), and yet the bytes in range [0x9ca17e7, 0x9ca17e9) also seem to get modified. -

Bug#710471: broken symlink /usr/lib/jvm/java-1.5.0-gcj

Package: gcj-jre-headless Version: 4:4.7.2-1 Severity: important This package contains the broken symlink /usr/lib/jvm/java-1.5.0-gcj -> java-1.5.0-gcj-4.7 The correct target is presumably /usr/lib/jvm/java-1.5.0-gcj-4.7-i386 (with the architecture). -- System Information: Debian Release: jes

Bug#714976: gcc-4.8-source: FTBFS cross-compiler for armel

error: fakeroot debian/rules binary gave error exit status 2 -- Peter C -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (

Bug#757738: Internal compiler error in simplify_const_unary_operation while building libwebp for arm64.

peter green wrote: While building libwebp on arm64 we got two internal compiler errors. The libwebp maintainer has told me (and I have confirmed) that this bug can be worked around with -frename-registers -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of

Bug#758964: gcc-4.9 assembler errors when building md5 code from fbb on arm64

Package: gcc-4.9 Version: 4.9.1-7 x-debbugs-cc: f...@packages.debian.org Control:| affects -1 fbb| While building the latest version of fbb (the previous version built successfully) for arm64 the autobuilders (both on debian-ports and debian official) ran into the following error. They were usi

Re: RFC: Adding minimal amd64/biarch support for sarge

hat some would call a "production" system). It would rock to have it in sarge :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set

Bug#268115: gcc-3.4: could optimize FP multiplies better

Package: gcc-3.4 Version: 3.4.1-7.0.0.1.amd64 Severity: wishlist compiling this function: double baz(double foo, double bar) { return foo*foo*foo*foo*bar*bar*bar*bar; } on amd64 with -O6 -ffast-math, gcc emits this code: foo.o: file format elf64-x86-64 Disassembly of section .text: ..

Bug#268023: Any success?

Hi, guys! Do you have any success with this glibc problem? Can you point me at thread or bug where glibc problem is discussed? Peter. -- Antispam protection: don't remove_these_lines_if you're not in my whitelist (replying first time). If you do, you'll have to make addit

Re: libunwind in unstable

> "Matthias" == Matthias Klose <[EMAIL PROTECTED]> writes: Matthias> Matthieu Delahaye writes: >> On Wed, 2004-11-24 at 17:36, Ian Wienand wrote: > On Wed, Nov 24, >> 2004 at 12:46:12AM +0100, Matthias Klose wrote: > > ok, Ian, if >> it's ok with you, I'll prepare a libunwind upload, which > >

Weird assembler messages with GCC 4.0

So I wanted to recompile a C++ package with GCC 4.0 as was announced a few hours ago and it gave me quite puzzling warnings along the way. In particular, I get a whole bunch of warnings like this: g++ -DHAVE_CONFIG_H -I. -I. -I../include -I../lua/include -I../lua/local -DLIBDIR=\"/usr/lib\" -I/u

Re: Weird assembler messages with GCC 4.0

Matthias Klose wrote: > please can you recheck with binutils 2.16 from experimental, That one works. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#197375: gcj dies when parsing java code with high ASCII values in it

th this, could gcj be made to handle these characters too? Thanks, Peter

Bug#197375: gcj dies en parsing java code with high ASCII values in it

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi... On Sun, 15 Jun 2003 01:28 am, Martin v. Löwis wrote: > Peter Hawkins <[EMAIL PROTECTED]> writes: > > gcj doesn't appear to like high-valued characters in it's input stream. > > Please don't use the term

Bug#197375: gcj dies en parsing java code with high ASCII values in it

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi... On Sun, 15 Jun 2003 08:30 pm, you wrote: > Peter Hawkins wrote: > > I've never touched the locale on my systems, so it's the default > > (LANG="C"?) > > Please invoke locale(1) to be sure. Yup, all of

Bug#228506: gcc-3.3: initalizing to zero equals uninitialised

Package: gcc-3.3 Version: 1:3.3.3-0pre2 Severity: important If I have a static variable initialized to 0 it ends up as uninitialized. See below. Compiling this with gcc-3.2 yields a correct result. $ cat test.c #include int main(void) { static int a; static int b = 0; static int c =

Bug#95253: upgrading from potato to sid, perl: /lib/libc.so.6: version `GLIBC_2.2' not found (required by /lib/libdb.so.3)

Package: perl Severity: minor I am really confused what component caused this bug, so this was filed against perl, and cc'd to the libstdc and dpkg maintaner. Please reassign the bug if you feel to know where it does belong. While upgrading from potato to sid the following happened while 'apt-get

Bug#101795: dist-upgrade fails: perl: /lib/libc.so.6: version `GLIBC_2.2' not found (required by /lib/libdb.so.3)

0-dev bug, a perl bug, a libc6 bug or a libdb2/libdb3 bug :-> Presumably one of these packages isn't setting its dependencies up correctly... I was able to fix this with "dpkg --configure -a; apt-get -f install"; the log of those commands is also here. Hope this helps, Peter Ma

Bug#133257: gcc: Assembler errors when compiling with -funroll-loops

ude -DNEED_GNOMESUPPORT_H -I/usr/lib/gnome-libs/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I../../src -I../../src-I../../src/drive -I../../src/raster -I../../src/monitor-g -O5 -funroll-loops -DNO_REGPARM -Wall -Winline -c vic20via2.c /home/pe

gcc-2.95.3

seems to be based on the 2.95.2 source code. is that right? should i switch to the raw 2.95.3 source from gcc.gnu.org? -- peter koellner <[EMAIL PROTECTED]>

Re: gcc-2.95.3

ls of that error. -- peter koellner <[EMAIL PROTECTED]>

Re: gcc-2.95.3

t sourcelist, kernel config file attached, gcc version 2.95.4-9. have fun! -- peter koellner <[EMAIL PROTECTED]> # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_

Re: gcc-2.95.3

porting bugs i have to use 2.95.3 so the code maintainer gets relevant input and does not have to double-check to reproduce the error. simple. -- peter koellner <[EMAIL PROTECTED]>

Re: gcc-2.95.3

stem for kernel development tasks, so that i don't get a response of "use the right compiler version, idiot!" when i send in some bug report to a kernel code maintainer. see the point too? ;-) -- peter koellner <[EMAIL PROTECTED]>

Re: gcc-2.95.3

local gcc. so i use the standard gcc 2.95.3 from gcc.gnu.org, and everything is fine, all questions answered. and i don't forbid anybody to use a different version, because i am in a very generous mood today ;-) -- peter koellner <[EMAIL PROTECTED]>

Re: gcc-2.95.3

s 2.95.4, plus some CVS patches. Yeah, maybe parts like libg++ > are still the same version as from 2.95.2, but that's not the compiler. i have that from http://packages.debian.org/testing/devel/gcc.html, at the Source Code line: Source Code: [dsc] [gcc_2.95.2.orig.tar.gz] [gcc_2.95.2-20.diff

  1   2   >