> Step 3: Start making the case upstream with the gcc SC, or at least try.
> As you've pointed out, it takes forever to get rid of an option
> or change it in gcc, which is understandable in a way, so why not
> start sooner than later, right? :-)
Exactly.
> The latter is u
> Ugh, yep. Recompiling the dependencies also with the current toolchain
> should fix this, correct? I'm not saying to do it, but it would be an
> interesting experiment if all else fails (read: weapon of last resort).
I think there are still problems compiling glibc with gcc 3; glibc
will clai
On Wed, 28 Nov 2001, Martin v. Loewis wrote:
> I think there are still problems compiling glibc with gcc 3; glibc
> will claim to export symbols from libgcc, when it really can't (since
> the symbols in libgcc_s won't be incorporated into glibc). I believe
> there are patches circulating to solve
On Wed, Nov 28, 2001 at 06:59:27AM +0100, Martin v. Loewis wrote:
> > I could have sworn it was NTFS...
> >
> > util.h:
> > typedef enum {
> > FILE_$Mft = 0,
> > FILE_$MftMirr = 1,
>
> What kernel version? In 2.4.10, this reads
>
> typedef enum {
> FILE_Mft=
Processing commands for [EMAIL PROTECTED]:
> reassign 120333 g++
Bug#120333: menu: update-menus gets Bus Error on mips
Bug reassigned from package `menu' to `g++'.
>
End of message, stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(adm
Processing commands for [EMAIL PROTECTED]:
> reassign 118814 g++-2.95
Bug#118814: ecawave: compile fails with internal compiler error on alpha
Bug reassigned from package `ecawave' to `g++-2.95'.
> severity 118814 normal
Bug#118814: ecawave: compile fails with internal compiler error on alpha
Sev
Processing commands for [EMAIL PROTECTED]:
> reassign 115978 libstdc++2.10
Bug#115978: stringstream adds extra characters at the end (forwarded from
libstdc++2.10-dev)
Bug reassigned from package `libstdc++2.10-glibc2.2' to `libstdc++2.10'.
> thanks
Stopping processing here.
Please contact me i
Your message dated Wed, 28 Nov 2001 17:59:20 +
with message-id <[EMAIL PROTECTED]>
and subject line works for me
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 responsibility to reo
Processing commands for [EMAIL PROTECTED]:
> reassign 94955 libstdc++2.10
Bug#94955: Linking with libstdc++ changes behavior of a program (which does not
require libstdc++)
Bug reassigned from package `libstdc++2.10-glibc2.2' to `libstdc++2.10'.
> reassign 52382 libstdc++2.10
Bug#52382: [fixed w
Your message dated Wed, 28 Nov 2001 18:24:45 +
with message-id <[EMAIL PROTECTED]>
and subject line submitter requested close
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 responsi
Your message dated Wed, 28 Nov 2001 18:30:48 +
with message-id <[EMAIL PROTECTED]>
and subject line upstream closed bug
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 responsibility
Your message dated Wed, 28 Nov 2001 18:28:06 +
with message-id <[EMAIL PROTECTED]>
and subject line not a bug
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 responsibility to reopen
Package: libgcj2
Version: 1:3.0.2-3
Severity: important
Tags: patch
Serialization of the java.util.Date class is broken in libgcj.
Although the "Date" class is correctly marked as "implements
java.io.Serializable", the actual data stored in the Date class is
marked transient! This means that the
Package: libgcj2
Version: 1:3.0.2-3
Severity: normal
The implementation of ObjectInputStream.readObject() in this version
of libgcj calls the constructor of the serialize object it is reading.
Sun's implementation does not do this, nor (I think) did earlier
versions of libgcj. Below is a sample p
Package: libstdc++3
Version: 1:3.0.2-3
Severity: normal
Hi!
I have seen an strange behaviour of libstdc++ regarding buffering of
streams; I don't know if it is my fault or the libraries fault. It
basically writes character per character whenever I do a cout <<
"something".
Given the fol
> I tried to investigate and found nothing. I was thinking maybe
> there is a switch for it or something, but found none. Anyway, by
> default, the output should be buffered, AFAIK ... and unless I am
> missing anything.
>
> Any clues?
That appears to be the implementation of the requirement that
> That appears to be the implementation of the requirement that
> std::cout and std::stdout are always synchronized (i.e. tied).
> This is done in ios.cc
>
> ...
>
> In gcc 2.95, tieing stdout and cout was achieved by having the same
> buffer objects. Since the ABI changed, and since the buffer i
17 matches
Mail list logo
