Processing commands for [EMAIL PROTECTED]:
> reassign 169004 gcc
Bug#169004: fping makes unaligned mem accesses, emulated by ia64 kernel
Bug reassigned from package `fping' to `gcc'.
> merge 85468 169004
Bug#85468: gcc: [alpha] memcpy makes unaligned access
Bug#169004: fping makes unaligned mem a
reassign 169004 gcc
merge 85468 169004
quit
On Wed, Nov 13, 2002 at 04:06:01PM -0700, dann frazier wrote:
> Package: fping
> Version: 2.4b2-to-ipv6-5
> Severity: normal
>
> fping makes unaligned accesses on ia64.
> such accesses are emulated in the kernel, and are therefore costly,
> and causes t
On Sat, Nov 16, 2002 at 01:20:33AM +0100, Florian Weimer wrote:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> >> -rw-r--r--1 willywilly 1884666 Nov 14 09:26
> >> gcc-3.2_3.2.1ds5-0pre6.diff.gz
> >
> > the big diff is the pregenerated libstdc++ documentation.
I thought the library
Matthias Klose <[EMAIL PROTECTED]> writes:
>> -rw-r--r--1 willywilly 1884666 Nov 14 09:26
>> gcc-3.2_3.2.1ds5-0pre6.diff.gz
>
> the big diff is the pregenerated libstdc++ documentation. The pages
> are generated using doxygen and graphviz. Unfortunately graphviz is in
> non-free ...
Thank you Phil.
So the only way to go around this is to use libstdc++3 and gcc3 or
use 2.90.8 which may or may not be completely standard conforming.
Thanks
Ranjan
-Original Message-
From: Phil Edwards [mailto:[EMAIL PROTECTED]
Sent: Friday, November 15, 2002 2:16 PM
To: Ranjan Parthas
On Fri, Nov 15, 2002 at 02:10:09PM -0800, Ranjan Parthasarathy wrote:
> Hi
>
> I am using a woody system and using the 2.95.4 version of the GNU compiler.
> The standard c++ library (2.10)
> seems to miss out on some essential headers that are required as per
> standard c++ compliance and this is
Hi
I am using a woody system and using the 2.95.4 version of the GNU compiler.
The standard c++ library (2.10)
seems to miss out on some essential headers that are required as per
standard c++ compliance and this is causing
problems with some our code that runs on multiple platforms and assumes a
Whatever this foul-up of yours is, please delete me. I suddenly received
this e-mail with this enormous cc: list. The site, which I've given up
waiting for, (so I have no idea who you are) is taking forever to load, and
I'm simply not interested. If I were, I'd send you an inquiry. I don't take
>Category: c++
>Synopsis: g++ Omtermal compiler error in
>merge_blocks_move_predecessor_nojumps, at cfgcleanup.c:650
>Confidential: no
>Severity: serious
>Priority: medium
>Class: sw-bug
>Submitter-Id: net
>Originator: [EMAIL PROTECTED]
>Release:g++
At 15 Nov 2002 06:16:38 -0800,
Daniel Schepler wrote:
> Package: pbuilder
> Version: 0.48
> Severity: normal
>
> This error happens trying to use pbuilder to build gcc-3.0:
>
Ermm... is this really a good idea to go around randomly removing
essential packages from build machines through speci
Philip Blundell writes:
> Package: gcc-3.1
> Version: 1:3.1.1ds3-3
> Severity: serious
>
> libstdc++ doesn't compile with glibc 2.3 headers. Its locale-related
> files make copious use of symbols that are no longer declared (e.g.
> __strtod_l, __newlocale, __ctype_toupper).
I asked on [EMAIL PRO
Philip Blundell writes:
> On Fri, 2002-11-15 at 12:41, Martin v. Loewis wrote:
> > Philip Blundell <[EMAIL PROTECTED]> writes:
> >
> > > Autoconf 2.50 doesn't seem to work for building gcc 3.1 (it triggers the
> > > "recursion limit reached" problem). For gcc-3.0, changing the build
> > > depende
On Fri, 2002-11-15 at 12:41, Martin v. Loewis wrote:
> Philip Blundell <[EMAIL PROTECTED]> writes:
>
> > Autoconf 2.50 doesn't seem to work for building gcc 3.1 (it triggers the
> > "recursion limit reached" problem). For gcc-3.0, changing the build
> > dependency from autoconf to autoconf2.13 fi
Philip Blundell <[EMAIL PROTECTED]> writes:
> Autoconf 2.50 doesn't seem to work for building gcc 3.1 (it triggers the
> "recursion limit reached" problem). For gcc-3.0, changing the build
> dependency from autoconf to autoconf2.13 fixed this, and I guess the
> same would work for gcc-3.1.
I tho
Package: gcc-3.1
Version: 1:3.1.1ds3-3
Severity: serious
libstdc++ doesn't compile with glibc 2.3 headers. Its locale-related
files make copious use of symbols that are no longer declared (e.g.
__strtod_l, __newlocale, __ctype_toupper).
Package: gcc-3.1
Version: 1:3.1.1ds3-3
Severity: serious
Justification: arm autobuilder can't cope otherwise
Autoconf 2.50 doesn't seem to work for building gcc 3.1 (it triggers the
"recursion limit reached" problem). For gcc-3.0, changing the build
dependency from autoconf to autoconf2.13 fixed
Your message dated Fri, 15 Nov 2002 07:54:56 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Processed: Re: Bug#169139: Problem with libstdc++-libc6 [ with
how-to-fix ]
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt wi
Your message dated Fri, 15 Nov 2002 07:54:56 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Processed: Re: Bug#169139: Problem with libstdc++-libc6 [ with
how-to-fix ]
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt wi
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> This should presumably be reported to GCC rather than to us...
> Libstdc++ folks, please maintain the CC's. Any thoughts?
GCC is clearly behaving correctly. typedefs are resolved before
mangling, since symbols that differ only in typedef usage mus
19 matches
Mail list logo
