test
This Email has been scanned for all viruses by PAETEC Email Scanning Services,
utilizing MessageLabs proprietary SkyScan infrastructure. For more information
on a proactive anti-virus service working around the clock,
Package: libstdc++3-dev (1:3.0.4-7) , g++-3.0 (1:3.0.4-7)
Version: 1:3.0.4-7
When attempting to install packages
libstdc++3-dev (1:3.0.4-7) and g++-3.0 (1:3.0.4-7)
using dpkg -i package, the following (below) is output
implying a inter-dependency on the installation of both packages.
After
Your message dated Tue, 29 Jun 2004 09:56:04 +0200
with message-id [EMAIL PROTECTED]
and subject line Bug#256801: Cannot Install libstdc++3-dev, g++-3.0 In Stable
Distribution
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt
PROTECTED]
for [EMAIL PROTECTED]; Sat, 27 Jul 2002 22:38:59 +0300
Received: from markuskj by lappa with local (Exim 3.35 #1 (Debian))
id 17YXP4-00035X-00; Sat, 27 Jul 2002 22:39:02 +0300
Subject: g++-3.0: c++ symlink and alternatives are not created when installing
From: Markus Järvinen
Hi,
I can confirm this. It's still there in gcc 3.4 20030629. Test case:
void f (int a)
{
__imag__ a;
}
--
Falk
Whoops, compiled the wrong file. Test case:
void f (void)
{
struct { } a;
__imag__ a;
}
Only occurs with g++, not gcc.
--
Falk
Your message dated Sat, 17 May 2003 17:32:56 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#85934: fixed in gcc-3.3 1:3.3ds9-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now
Your message dated Sat, 17 May 2003 17:32:56 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#83363: fixed in gcc-3.3 1:3.3ds9-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now
Your message dated Sat, 17 May 2003 17:32:54 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#61806: fixed in gcc-3.3 1:3.3ds9-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now
Your message dated Sat, 17 May 2003 17:32:42 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#105569: fixed in gcc-3.3 1:3.3ds9-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now
Your message dated Sat, 17 May 2003 17:32:56 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#88260: fixed in gcc-3.3 1:3.3ds9-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now
Your message dated Sat, 17 May 2003 17:32:43 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#141797: fixed in gcc-3.3 1:3.3ds9-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now
Your message dated Sat, 17 May 2003 17:32:42 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#128367: fixed in gcc-3.3 1:3.3ds9-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now
Your message dated Sat, 17 May 2003 17:32:42 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#127489: fixed in gcc-3.3 1:3.3ds9-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now
Your message dated Sat, 17 May 2003 17:32:42 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#118781: fixed in gcc-3.3 1:3.3ds9-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now
Package: g++-3.0
Version: 1:3.0.4-7
Severity: wishlist
Tags: patch
There is a small typo (an extra period) in the README.Debian
file of gcc-3.0. The patch is inline below.
--- README.Debian.orig 2003-01-28 21:18:13.0 -0500
+++ README.Debian 2003-01-28 21:18:21.0 -0500
Your message dated Sat, 16 Nov 2002 13:50:55 +0100
with message-id [EMAIL PROTECTED]
and subject line Bug#144409: g++-3.0: does not support transform(begin,end,be
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt
Package: g++-3.0
Version: 1:3.0.4-7
Severity: normal
The source below makes G++-3.0 report a syntax error where none exists.
Basically it doesn't wait before giving up on the typename.
// Comment out to make it work.
#define BREAK
struct a {
struct b {
typedef unsigned int foo_t
Processing commands for [EMAIL PROTECTED]:
retitle 158371 [fixed in g++-3.2] internal compiler error in expand_end_loop
with -O
Bug#158371: g++-3.0: internal compiler error in expand_end_loop with -O
Changed Bug title.
tags 158371+ fixed
Unknown command or malformed arguments to command
Package: g++-3.0
Version: 1:3.0.4-12
Severity: important
I get:
Internal compiler error in expand_end_loop, at stmt.c:2527
when compiling a class from our code. I don't see anything
particularly wrong about the code, but it is part of a large code base
so I can't easily extract a simple
As a short-term cludge (for those that require one); change the link
line in your makefiles to link in stdc++ before you link in glut/GLU.
By default, stdc++ will be linked in afterwards, but forcing it up the
list allows its symbols to become visible to your app.
It isn't clean; it isn't pretty;
reassign 154525 gcc
severity 154525 wishlist
merge 154525 112887
thanks
gcc-3.0/g++-3.0 doesn't use alternatives to make sure that the
preferred system compiler is used when calling 'gcc'. If you want to
test gcc-3.0/g++-3.0 for a particular package,
- use CC=gcc-3.0 CXX=g++-3.0 when configuring
Processing commands for [EMAIL PROTECTED]:
reassign 154525 gcc
Bug#154525: g++-3.0: c++ symlink and alternatives are not created when
installing
Bug reassigned from package `g++-3.0' to `gcc'.
severity 154525 wishlist
Bug#154525: g++-3.0: c++ symlink and alternatives are not created when
Package: g++-3.0
Version: 1:3.0.4-12
Severity: normal
Alternatives for /usr/bin/c++ are not created/updated when installing g++-3.0.
-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux lappa 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i586
Locale: LANG=C, LC_CTYPE=C
Versions
:28:49 +0200
From: Zdenek Kabelac [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: g++-3.0: coredump with dynamic_cast
X-Mailer: reportbug 1.49
Date: Thu, 04 Apr 2002 23:28:49 +0200
Message-Id: [EMAIL PROTECTED]
Sender: Zdenek Kabelac [EMAIL PROTECTED]
Delivered-To: [EMAIL
Processing commands for [EMAIL PROTECTED]:
reassign 134262 glut3g
Bug#134262: g++-3.0: Use of dynamic_cast makes compiled program segfault
Bug reassigned from package `g++-3.0' to `glut3g'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system
/specs
(B Configured with: ../../../3.0.3/configure --prefix=/sw/gcc-3.0.3
(B --disable-shared --disable-libgcj
(B Thread model: single
(B gcc version 3.0.3
(B
(B Works.
(B
(B [EMAIL PROTECTED]:~$ g++-3.0 -v
(B Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.3/specs
(B Configured
Processing commands for [EMAIL PROTECTED]:
retitle 105569 [fixed in g++-3.0] [mips] g++ exception catching does not
work...
Bug#105569: [mips] [mips/mipsel] g++ exception catching does not work...
Changed Bug title.
End of message, stopping processing here.
Please contact me if you need
There appear to (still) be some issues with g++-3.0 on ia64. Under some
optimisation switches, the executable is built, but segfaults. Under others,
g++-3.-0 dies.
fwiw with gcc version 3.1 20020331 (prerelease) the problem appears to
be fixed. I think this might be the same/related to pr/5363
There appear to (still) be some issues with g++-3.0 on ia64. Under some
optimisation switches, the executable is built, but segfaults. Under others,
g++-3.-0 dies.
fwiw with gcc version 3.1 20020331 (prerelease) the problem appears to
be fixed. I think this might be the same/related
Is that one available somewhere on an ia64 box, preferably one accessible
to John?
gcc-snapshot package, but we cannot use that to build binaries to go into the
archive (uses different library versions)
I'm not sure which box John has access to, but mail
[EMAIL PROTECTED] and they can install
maybe if linking with static libraries is an option?
i guess that's always possible, but kinda ugly.
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: g++-3.0
Version: 1:3.0.4-7
Severity: important
The following bug report owes a lot to John Eaton's work. I reported a
problem with the octave2.1 package on the ia64 platform to him, the upstream
authors. Bdale kindly provided an account on ia64 for John.
There appear to (still
Package: g++-3.0
Version: 1:3.0.4-7
Severity: normal
the code below is from Josuttis' The C++ standard library and I have seen it
elsewhere. It works under 2.95.4.
#include string
#include algorithm
#include cctype
#include iostream
using namespace std;
int main(int argc, char* argv
[Nicolai, if you disagree with the analysis below, please let us know]
Sean Perry [EMAIL PROTECTED] writes:
the code below is from Josuttis' The C++ standard library and I
have seen it elsewhere. It works under 2.95.4.
AFAICT, the code is incorrect.
int main(int argc, char* argv[]) {
int main(int argc, char* argv[]) {
string foo = Some Mixed Case Text;
cout foo endl;
transform(foo.begin(), foo.end(), foo.begin(), tolower);
The compiler can't properly resolve tolower: The problem is that
tolower is not only a function in namespace std, it is also a
On Thu, Apr 04, 2002 at 11:06:18PM +0100, Philip Blundell wrote:
On Thu, 2002-04-04 at 22:28, Zdenek Kabelac wrote:
Just today I've recompiled avifile with latest gcc3.0
and with Qt compiled with gcc3.0 so I could actually try how this
works - and I've discovered that dynamic_cast with
On Fri, 2002-04-05 at 08:16, Zdenek Kabelac wrote:
Hmm looks like it - but there are two interesting points however
- somehow I've not noticed this report while using reportbug
- I do not link libGLU to avifile - but as it's linked with libSDL
libGL seems to be linked with the program - but
On Fri, Apr 05, 2002 at 09:18:47AM +0100, Philip Blundell wrote:
On Fri, 2002-04-05 at 08:16, Zdenek Kabelac wrote:
Hmm looks like it - but there are two interesting points however
- somehow I've not noticed this report while using reportbug
- I do not link libGLU to avifile - but as it's
Package: g++-3.0
Version: 1:3.0.4-6
I can confirm the problem exists for the QGLViewer package (uses
qt, pthreads, GL) - SIGSEGV at the first dynamic_cast. gcc 2.95.x
do not have this problem. gcc-3_0 branch HEAD has the same problem.
The SIGSEGVs vanish, if I remove -lGLU from the final link
Package: g++-3.0
Version: 1:3.0.4-6
I can confirm removing -lGLU from the link command line solves the
same problem with the QGLViewer package (using Qt and GL - linking
with GLU is from the tmake configuration).
Note that this happens on a SuSE 7.2 system, too (g++ from HEAD of the
gcc-3_0
Package: g++-3.0
Version: 1:3.0.4-6
The problem is both libGLU.so and libstdc++ contain the symbol
__dynamic_cast which is used by gcc to apply the cast. Anytime
the GLU one takes over, the SIGSEGVs occour (can be checked by
LD_PRELOADing libGLU to any dynamic_cast using program!).
So libGLU
Package: g++-3.0
Version: 1:3.0.4-6
Severity: normal
Hi
Just today I've recompiled avifile with latest gcc3.0
and with Qt compiled with gcc3.0 so I could actually try how this
works - and I've discovered that dynamic_cast with this
gcc no longer works and actually creates coredump
05:07:59 +1100 (EST)
Received: from flatmax by maillationax with local (Exim 3.35 #1 (Debian))
id 16qHn6-0006B6-00
for [EMAIL PROTECTED]; Thu, 28 Mar 2002 05:04:56 +1100
Date: Thu, 28 Mar 2002 05:04:55 +1100
To: [EMAIL PROTECTED]
Subject: g++-3.0, result of using the : undefined
Processing commands for [EMAIL PROTECTED]:
tags 140186 + unreproducible
Bug#140186: g++-3.0, result of using the : undefined symbol: __dso_handle
Tags added: unreproducible
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
Please find attatched a complete shared library project and Makefile.
a] tar zxpvf g++-3.0-possible-bug.tar.gz ; cd g++-3.0-possible-bug
b] make
c] export LD_LIBRARY_PATH=.
d] /sbin/ldconfig
e] ./HelloWorldExample
./HelloWorldExample: relocation error: ./libHelloWorld.so.1: undefined
symbol
and Makefile.
a] tar zxpvf g++-3.0-possible-bug.tar.gz ; cd g++-3.0-possible-bug
b] make
c] export LD_LIBRARY_PATH=.
d] /sbin/ldconfig
e] ./HelloWorldExample
./HelloWorldExample: relocation error: ./libHelloWorld.so.1: undefined
symbol: __dso_handle
That is the result !
Info again
tags 140186 + unreproducible
thanks
I'm not able to replicate this bug. Can you send a complete test-case
that shows the problem?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Thu, Mar 28, 2002 at 05:04:55AM +1100, mffm Matt Flax wrote:
Compilation is fine. When I try to execute, I get the following
problem :
relocation error:
undefined symbol: __dso_handle
You need either a much older binutils, or a newer one. For GCC 3.x I
recommend the latter.
Phil
--
/specs
Configured with: ../../../3.0.3/configure --prefix=/sw/gcc-3.0.3
--disable-shared --disable-libgcj
Thread model: single
gcc version 3.0.3
Works.
[EMAIL PROTECTED]:~$ g++-3.0 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.3/specs
Configured with: ../src/configure -v
--enable-languages=c,c
Package: g++-3.0
Version: 1:3.0.4-0pre020210
Severity: important
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux abyss 2.4.16 #1 Tue Nov 27 04:00:11 CET 2001 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages g++-3.0 depends on:
ii gcc-3.0 1:3.0.4
Daniel Sjlie [EMAIL PROTECTED] writes:
0x400a9c59 in osgDB::ReaderWriter::ReadResult::getNode() (this=0xb2a0)
at /home/source/osg/cvs/include/osgDB/ReaderWriter:64
64 osg::Node* getNode() { return
dynamic_castosg::Node*(_object.get()); }
(gdb) s
Program
On 2002-02-16 23:01:21, Martin v. Loewis wrote:
Daniel Sjölie [EMAIL PROTECTED] writes:
0x400a9c59 in osgDB::ReaderWriter::ReadResult::getNode() (this=0xb2a0)
at /home/source/osg/cvs/include/osgDB/ReaderWriter:64
64 osg::Node* getNode() { return
Daniel Sjölie [EMAIL PROTECTED] writes:
Not sure, not my code, but would gdb say this if it wasn't true?
(gdb) print _ptr
$5 = (Object *) 0x808f170
It certainly would. gdb just reports what the compiler (and thus the
code) claims to be the static type of the pointer.
Regards,
Martin
possibly include a glibc header, otherwise certain C++ programs will
simply fail out of the box.
I don't believe that this is true.
[...]
http://gcc.gnu.org/ml/libstdc++/2000-12/msg00215.html
Well, there's my example. :-)
Just to make sure we are talking about the same
If you have questions (or better yet, patches *grin*), by all means include
the list. However, if you do, I'd recommend /not/ cc'ing @bugs.debian.org,
because those auto-acks are awfully annoying.
{Removing [EMAIL PROTECTED], adding [EMAIL PROTECTED]
See http://bugs.debian.org/126703 for
That would remove the need to define _GNU_SOURCE in the command line.
There are other related problems, such as #108663. It seems that
_GNU_SOURCE is required anyway when using g++-3.0.
Well, I'm proposing to fix the dependency of libstdc++ to require
_GNU_SOURCE (which is passed through
Martin v. Loewis writes:
I can't see a reason for libstdc++ requiring _GNU_SOURCE except for the
desire to re-export symbols in std::, for which I would propose a
different strategy.
It would help to know why this was done in the first place; there could be
other reasons.
Sure,
On Mon, Dec 31, 2001 at 01:38:06AM +0100, Matthias Klose wrote:
Martin v. Loewis writes:
I can't see a reason for libstdc++ requiring _GNU_SOURCE except for the
desire to re-export symbols in std::, for which I would propose a
different strategy.
It would help to know why this
_GLIBCPP_USE_C99 1
#endif
That would remove the need to define _GNU_SOURCE in the command line.
There are other related problems, such as #108663. It seems that
_GNU_SOURCE is required anyway when using g++-3.0.
--
- mdz
This is evil ;-)
I agree. It would be better if c++config.h would take compiler and
library configurations into account. For *-*-linux-gnu, c++config.h
should contain fragments like
#ifdef __USE_ISOC99
#define _GLIBCPP_USE_C99 1
#endif
That would remove the need to define _GNU_SOURCE in the
Package: g++-3.0
Version: 1:3.0.2-3
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Accidentally leaving the close brace off of a block in e.g., a header
file will often result in errors in files that include it, without any
indication of what is wrong. For example, leaving
];
Tue, 23 Oct 2001 23:07:47 -0700
Received: from pat by pizza.saltlk1.ut.home.com with local (Exim 3.32 #1
(Debian))
id 15wHJS-0001yH-00; Wed, 24 Oct 2001 00:14:50 -0600
From: Patrick Tullmann [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: g++-3.0: nested
On Wed, 24 Oct 2001, Matthias Klose wrote:
hmm, I was under the impression, that enabling -fuse-cxa-atexit as the
default on a glibc-2.2 based system, was safe.
You get the code you want with -fno-use-cxa-atexit. Should we revert
this change?
After analyzing the problem it became clear that
Martin v. Loewis wrote:
When compiling the same programs with these compilers, g++ 2.95 is
much (sometimes 3 times) faster than g++ 3.0, even without
optimizing (without -O).
Not sure what you asking. Are you saying g++ 2.95 is faster, or that
the generated code is faster?
Why
Why is it happening? Is it so because of more complex templates in recent
libstdc++?
If you are asking for compilation speed, yes, the main cause it that
libstdc++ consists of many more templates now. If you are asking for a
slow-down in an application, you need to provide detailed
Yes. Not only has the libstdc++ ABI changed, but the symbol mangling has
as well (hence most of the undefined symbols that you're seeing). I've
tested gcc/g++ 3.0 out on KDE on Alpha before and it worked fairly
well. There were some problems (Konqueror crashed for no reason, etc
Hello all.
When compiling the same programs with these compilers, g++ 2.95 is much
(sometimes 3 times) faster than g++ 3.0, even without optimizing (without -O).
Why is it happening? Is it so because of more complex templates in recent
libstdc++?
Is g++ 3.0 really a step further ?
Regards
When compiling the same programs with these compilers, g++ 2.95 is
much (sometimes 3 times) faster than g++ 3.0, even without
optimizing (without -O).
Not sure what you asking. Are you saying g++ 2.95 is faster, or that
the generated code is faster?
Why is it happening? Is it so because
I've been trying out gcc-3.0 (3.0.2) with some little Qt apps that I
wrote. The code compiles fine, but fails with tons of undefined
references Qwhatever objects when trying to link.
All is well, however, when linking with 2.95.4.
What's the problem? Do I need to rebuild the qt libs with 3.0
? Do I need to rebuild the qt libs with 3.0 to link
against them?
Yes. Not only has the libstdc++ ABI changed, but the symbol mangling has
as well (hence most of the undefined symbols that you're seeing). I've
tested gcc/g++ 3.0 out on KDE on Alpha before and it worked fairly
well. There were
On Wed, Oct 24, 2001 at 11:48:02PM +0200, Martin v. Loewis wrote:
Lots of real C++ code is order-sensitive. This is a serious problem and
there are a couple of ugly solutions to it.
I'd say that the best solution would be to get rid of globals. This is
actually very easy:
If you have
Package: g++-3.0
Version: 1:3.0.2-0pre010922
Severity: normal
File: /usr/bin/g++-3.0
The attached file demonstrates that g++ (in Debian/testing) barfs on a
nested int conversion of a static function in a constructor expecting
an int. (See the main local variable 'broken' in the example.) My
You get the code you want with -fno-use-cxa-atexit. Should we revert
this change?
I don't think so. I'm 90% positive that this is CLN's fault.
Inserting labels in the body of a function is a somewhat disgusting way
to do it!
I agree. There is no guarantee in the C++ language, or the
On Tue, 23 Oct 2001, Daniel Jacobowitz wrote:
[...]
hmm, I was under the impression, that enabling -fuse-cxa-atexit as the
default on a glibc-2.2 based system, was safe.
You get the code you want with -fno-use-cxa-atexit. Should we revert
this change?
I don't think so. I'm 90%
On Wed, 24 Oct 2001, Daniel Jacobowitz wrote:
[...]
Could you please provide a pointer or two to code samples or things that
might be helpful implementing it the Right Way, since I intend to try and
fix it? (Dunno if I'm old enough for this, though.)
Thanks a lot for all the input,
On Wed, 24 Oct 2001, Daniel Jacobowitz wrote:
sigh If you're order-sensitive, you've got a problem.
Lots of real C++ code is order-sensitive. This is a serious problem and
there are a couple of ugly solutions to it. The best solution would be to
teach the linker about it. The solution we are
On Wed, Oct 24, 2001 at 01:11:02AM +0200, Matthias Klose wrote:
Richard B. Kreckel writes:
Package: g++-3.0
Version: 1:3.0.2-0pre011014
Severity: important
Summary: It seems like some bug crept into Debian's gcc-3.0. The bug does
not seem to be present upstream. This bug renders
Zoltan Nagy wrote:
When I use the g++-3.0 ( gcc version 3.0.2 20010922 (Debian prerelease)
) the compiler doesn't link the libstdc++. It might be a bug.
Firstly, the compiler does not link at all. It is linker's task.
Secondly, the linker links it [libstdc++] fine for me (g++ is the same
Hi,
When I use the g++-3.0 ( gcc version 3.0.2 20010922 (Debian prerelease)
) the compiler doesn't link the libstdc++. It might be a bug.
Zoltan
-soft-float libstdc++3 libgcc1 gobjc-3.0
gcc-3.0-base libffi2-dev fastjar cpp-3.0-doc protoize cpp-3.0 g++-3.0 libobjc1
libstdc++3-dev g77-3.0 libstdc++3-doc libgcj2 g77-3.0-doc libffi2 fixincludes
gcc-3.0 libgcc1-sparc64 gcj-3.0 gcc-3.0-doc libstdc++3-dbg gcc-3.0-nof
libgcj2-dev
Architecture
Anthony Towns writes:
On Mon, Jul 23, 2001 at 09:32:26PM +0200, Matthias Klose wrote:
Christopher C. Chimelis writes:
On Mon, 23 Jul 2001, Matthias Klose wrote:
I don't like the current situation. we have a gcc version in woody
that should be removed and version in sid, which
Hello all.
I am faced with a problem: my classes hierarchy is not compiled by G++ 3.0
Debian prerelease.
I use woody branch and I don't want to switch to sid because I want to have a
somewhat stable system.
G++ 3.0 Debian prerelease ICEs on my (legal) code. I've wrote a bug report to
GNATS
Alexei Khlebnikov writes:
I am faced with a problem: my classes hierarchy is not compiled by G++ 3.0
Debian prerelease.
I use woody branch and I don't want to switch to sid because I want to have a
somewhat stable system.
G++ 3.0 Debian prerelease ICEs on my (legal) code. I've wrote
On Mon, 23 Jul 2001, Matthias Klose wrote:
I don't like the current situation. we have a gcc version in woody
that should be removed and version in sid, which doesn't
propagate.
What's the hold-up on the sid-woody move for gcc-3.0 (I haven't seen
update-excuses yet)? I can't think of any
What's the hold-up on the sid-woody move for gcc-3.0 (I haven't seen
update-excuses yet)? I can't think of any reason to keep the version in
woody around at all...
It has an RC bug, #105246. Update-excuses also mentions some problem with the
doc packages but this looks like it may be spurious.
#103980- [PR c++/3702] gcc-3.0 copies constructors, a build error
in the sfs package.
#105246:- [PR c++/3774 arm] can't compile a trivial program including
string
I just downgraded those two to important. They have been forwarded upstream,
they aren't
Christopher C. Chimelis writes:
On Mon, 23 Jul 2001, Matthias Klose wrote:
I don't like the current situation. we have a gcc version in woody
that should be removed and version in sid, which doesn't
propagate.
What's the hold-up on the sid-woody move for gcc-3.0 (I haven't
On Mon, Jul 23, 2001 at 09:32:26PM +0200, Matthias Klose wrote:
Christopher C. Chimelis writes:
On Mon, 23 Jul 2001, Matthias Klose wrote:
I don't like the current situation. we have a gcc version in woody
that should be removed and version in sid, which doesn't
propagate.
://www.mit.edu:8008/snafu.fooworld.org/sfs/116
Jaakko
Jaakko and related thread in the sfs mailing list arhive for
Jaakko more proper explanation.
Yes, I agree that this behaviour change is a bug in g++ 3.0. Making
the constructor public is a simple (an incorrect) workaround for g++
3.0 compilation. You
Submitter-Id: net
Originator:Jaakko Niemi [EMAIL PROTECTED]
Organization: The Debian project
Confidential: no
Synopsis: g++-3.0 copies constructors
Severity: serious
Priority: medium
Category: c++
Class: sw-bug
Release: 3.0 (Debian GNU/Linux)
Environment
Submitter-Id: ?
Originator:Franck Branjonneau
Organization:
Confidential: no
Synopsis: GCC gives an ICE instead of reporting an error.
Severity: non-critical
Priority: ?
Category: c++
Class: ice-on-illegal-code
Release: 3.0 (Debian) (Debian
On Fri, Jul 13, 2001 at 10:05:29AM +0200, Laurent Bonnaud wrote:
Hi,
you write that apparently, g++ 3.0 tries a longer conversion chain
than 2.95. Indeed, the compiler message let us think so. But to
verify this, I added traces into your testcase. The result is that
both g++ versions
Package: g++-3.0
Version: 3.0-4
Hello,
This bug report may need to be redirected to a different package
(cpp-3.0 or libstdc++3-dev).
Adding -I/usr/include to the compile line of g++-3.0 can cause
system headers in /usr/include to *not* be found. This is due to the
use of #include_next inside
Your message dated Sat, 14 Jul 2001 11:43:47 -0700
with message-id [EMAIL PROTECTED]
and subject line Bug#105238: g++-3.0 fails to find system headers when
-I/usr/include is used
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt
Package: g++-3.0
Version: N/A
Severity: normal
SFS fails to compile with gcc 3.0, and it was tracked down to this
example code that reproduces the error:
-
class aios {
friend class aiosout;
public:
aios ();
~aios ();
};
class aiosout {
aiosout (const aiosout o
Processing commands for [EMAIL PROTECTED]:
reassign 103674 libgtkmm-dev
Bug#103674: g++-3.0: #include string is broken when using -I/usr/include
Bug reassigned from package `g++-3.0' to `libgtkmm-dev'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Darren Benham
reassign 103674 libgtkmm-dev
thanks
On Thu, Jul 05, 2001 at 05:56:10PM -0700, Michael Babcock wrote:
Package: g++-3.0
Version: 1:3.0-4
Severity: normal
With g++ 3.0 if you have -I/usr/include on the command line,
#include string does not work properly.
Since `gtkmm-config --cflags
bonnaud by irancy.lis.inpg.fr with local (Exim 3.22 #1 (Debian))
id 15DO85-0008P5-00; Fri, 22 Jun 2001 12:25:33 +0200
From: laurent bonnaud [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: g++-3.0 and --use-cxa-atexit
X-Reportbug-Version: 1.18
X-Mailer: reportbug
Chris, any support in ld needed?
laurent bonnaud writes:
Package: g++-3.0
Version: 1:3.0-1
Severity: normal
Hi,
according to http://gcc.gnu.org/bugs.html#known, it would seem to be a good
idea to compile g++-3.0 with the --use-cxa-atexit switch:
Global destructors
1 - 100 of 105 matches
Mail list logo
