Processed: reassign gcc bug
Processing commands for [EMAIL PROTECTED]: > reassign 135651 gcc-2.95 Bug#135651: libstdc++2.10-dev: upgrade fails "version GLIBC_2.2 not found Bug reassigned from package `libstdc++2.10-dev' to `gcc-2.95'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#135651: libstdc++2.10-dev: upgrade fails "version GLIBC_2.2 not found
I don't think this is related to libstdc++2.10-dev (a dev package not containing any shared libs). > First significant bug is: > > Preparing to replace libstdc++2.10-dev 1:2.95.2-13 (using > .../libstdc++2.10-dev_1%3a2.95.4-1_i386.deb) ... > perl: /lib/libc.so.6: version `GLIBC_2.2' not found (required by > /lib/libdb.so.3) This is NOT the first bug, why does perl print the error message?
Bug#135709: gcc-3.0: missing (?) replaces
Package: gcc-3.0 Version: 1:3.0.4-1 Perhaps not an issue, but I thought I'd at least let you know. | Unpacking replacement gcc-3.0 ... | dpkg - warning, overriding problem because --force enabled: | trying to overwrite `/lib/64/libgcc_s_64.so', which is also in package libgcc1-sparc64 -- James
Bug#135727: buffer overflow (?) in writeln
Package: gpc Version: 2:2.95.4-9 When I print floating-point numbers, I sometimes get garbage like this: -:.00/+)))./(/0,,.0.-.0/,.-(e-15 Compile and run like this: gpc -O2 -g3 -Wall g2.p && ./a.out The problem seems to be caused by this: w := 44; p := 0; writeln(, -0.0001e-10:w, ); writeln(, -0.0001e-10:w:p, ); writeln(, 0.0001e-10:w, ); writeln(, 0.0001e-10:w:p, ); Feel free to include any of this code (above and/or below) in the gpc test suite. You can have it under the 2-clause BSD license. I have a 32-bit big-endian processor, the MPC7400 v2.9 (ppc "G4"). BTW, the assembly output for this code appears to be terribly inefficient. (only a minute of study though) Floating-point constants seem to get loaded multiple times instead of being kept in registers. For your wishlist, have -Os turn the code below into a loop over an array. @@ TEST CODE PROGRAM giga ( input,output ) ; var w:integer; p:integer; begin w := 44; p := 0; writeln(, 9.999e9, ); writeln(, 9.999e9:w, ); writeln(, 9.999e9:w:p, ); writeln(, 7.777e9:w:p, ); writeln(, 9.999e-10, ); writeln(, 9.999e-10:w, ); writeln(, 9.999e-10:w:p, ); writeln(, 7.777e-10:w:p, ); writeln(, 123.456, ); writeln(, 123.456:w, ); writeln(, 123.456:w:p, ); writeln(, 0.0001e-9, ); writeln(, 0.0001e-9:w, ); writeln(, 0.0001e-9:w:p, ); writeln(, 0.0001e-10, ); writeln(, 0.0001e-10:w, ); writeln(, 0.0001e-10:w:p, ); writeln(, -9.999e9, ); writeln(, -9.999e9:w, ); writeln(, -9.999e9:w:p, ); writeln(, -7.777e9:w:p, ); writeln(, -9.999e-10, ); writeln(, -9.999e-10:w, ); writeln(, -9.999e-10:w:p, ); writeln(, -7.777e-10:w:p, ); writeln(, -123.456, ); writeln(, -123.456:w, ); writeln(, -123.456:w:p, ); writeln(, -0.0001e-9, ); writeln(, -0.0001e-9:w, ); writeln(, -0.0001e-9:w:p, ); writeln(, -0.0001e-10, ); writeln(, -0.0001e-10:w, ); writeln(, -0.0001e-10:w:p, ); writeln(, -0.0/0.0:w:p, ); writeln(, 0.0/0.0:w:p, ); writeln(, -1.0/0.0:w:p, ); writeln(, 1.0/0.0:w:p, ); writeln(, -0.0/1.0:w:p, ); writeln(, 0.0/1.0:w:p, ); writeln(, -1.0/1.0:w:p, ); writeln(, 1.0/1.0:w:p, ); writeln(, -0.0/-0.0:w:p, ); writeln(, 0.0/-0.0:w:p, ); writeln(, -1.0/-0.0:w:p, ); writeln(, 1.0/-0.0:w:p, ); writeln(, -0.0/-1.0:w:p, ); writeln(, 0.0/-1.0:w:p, ); writeln(, -1.0/-1.0:w:p, ); writeln(, 1.0/-1.0:w:p, ); writeln end. @@ VERSION INFO ||/ Name VersionDescription +++-==-==- ii gpc2.95.4-9 The GNU Pascal compiler. ii libc6 2.2.4-7GNU C Library: Shared libraries and Timezone ii gcc2.95.4-9 The GNU C compiler. ii cpp2.95.4-9 The GNU C preprocessor. ii gpc-2.95 2.95.4-0.01100 The GNU Pascal compiler. ii gcc-2.95 2.95.4-0.01100 The GNU C compiler. Package: gpc Source: gcc-defaults (0.16) Version: 2:2.95.4-9 Package: libc6 Source: glibc Version: 2.2.4-7 Package: gcc Source: gcc-defaults (0.16) Version: 2:2.95.4-9 Package: cpp Source: gcc-defaults (0.16) Version: 2:2.95.4-9 Package: gpc-2.95 Source: gcc-2.95 (2.95.4.ds6-0.011006) Version: 1:2.95.4-0.011006 Package: gcc-2.95 Source: gcc-2.95 (2.95.4.ds6-0.011006) Version: 1:2.95.4-0.011006
Bug#135730: writeln radix control
Package: gpc Version: 2:2.95.4-9 The "pc" compiler on Tru64 (formerly OSF/1 or Digital UNIX) has radix control. NOTE: it is typed and works for negative values. I get stuff like "-FFF" from -4095 but "EE6CD998" from 4000111000. I've no idea how to get leading zeros on these. PROGRAM radix ( input,output ) ; begin writeln(, 4095:2:16, ); writeln(, 4095:3:16, ); writeln(, 4095:8:16, ); writeln(, 4095:9:16, ); writeln(, 4095:2:8, ); writeln(, 4095:4:8, ); writeln(, 4095:11:8, ); writeln(, 4095:12:8, ); writeln(, 4095:2:2, ); writeln(, 4095:6:2, ); writeln(, 4095:32:2, ); writeln(, 4095:36:2, ); writeln(, 4095:2:32, ); writeln(, 4095:3:32, ); writeln(, 4095:7:32, ); writeln(, 4095:8:32, ); writeln(, 4095:2:10, ); writeln(, 4095:4:10, ); writeln(, 4095:10:10, ); writeln(, 4095:12:10, ); writeln(, 4095:2, ); writeln(, 4095:4, ); writeln(, 4095:10, ); writeln(, 4095:12, ); writeln end. @ SAMPLE OUTPUT 'FFF' 'FFF' ' FFF' ' FFF' '' '' ' ' '' '' '' '' '' '3VV' '3VV' '3VV' ' 3VV' '4095' '4095' ' 4095' '4095' '4095' '4095' ' 4095' '4095'
Bug#135651: libstdc++2.10-dev: upgrade fails "version GLIBC_2.2 not found
On Mon, Feb 25, 2002 at 06:11:52PM +0100, Matthias Klose wrote: > I don't think this is related to libstdc++2.10-dev (a dev package not > containing any shared libs). As I said, the apt maintainer wasn't willing to accept the bug as their fault. Since libstdc++2.10-dev fails install and seems to cause catastophic failures with the dist-upgrade, you're second choice. > > First significant bug is: > > > > Preparing to replace libstdc++2.10-dev 1:2.95.2-13 (using > > .../libstdc++2.10-dev_1%3a2.95.4-1_i386.deb) ... > > perl: /lib/libc.so.6: version `GLIBC_2.2' not found (required by > > /lib/libdb.so.3) > > This is NOT the first bug, why does perl print the error message? You are welcome to look through the logs in http://www.blars.org/obfucsate/ and find an earlier falure to blame if you can. dist-upgrade2.gz is the relivent one for this. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Bug#135651: libstdc++2.10-dev: upgrade fails "version GLIBC_2.2 not found
On Mon, 2002-02-25 at 21:07, Blars Blarson wrote: > On Mon, Feb 25, 2002 at 06:11:52PM +0100, Matthias Klose wrote: > > I don't think this is related to libstdc++2.10-dev (a dev package not > > containing any shared libs). > > As I said, the apt maintainer wasn't willing to accept the bug as > their fault. Since libstdc++2.10-dev fails install and seems to cause > catastophic failures with the dist-upgrade, you're second choice. There is no point just trying to pin the blame on arbitrary packages. The fact that libstdc++2.10-dev won't configure is a symptom of the problem, not the cause. > > > First significant bug is: > > > > > > Preparing to replace libstdc++2.10-dev 1:2.95.2-13 (using > > > .../libstdc++2.10-dev_1%3a2.95.4-1_i386.deb) ... > > > perl: /lib/libc.so.6: version `GLIBC_2.2' not found (required by > > > /lib/libdb.so.3) It's fairly clear that this failure is caused by incompatible versions of libdb2 and libc6 having been installed. And, sure enough, a few lines higher up in your log you will see: Unpacking replacement libdb2-dev ... Replacing files in old package libc6-dev ... Preparing to replace libdb2-util 2:2.4.14-2.7.7.1.c (using .../libdb2-util_2%3a2.7.7.0-3.1_i386.deb) ... Unpacking replacement libdb2-util ... Preparing to replace libdb2 2:2.4.14-2.7.7.1.c (using .../libdb2_2%3a2.7.7.0-3.1_i386.deb) ... Unpacking replacement libdb2 ... Replacing files in old package libc6 ... I suggest you try reassigning the bug to libdb2. p.
Re: [Linux-ia64] gcc profiling broken on Linux/ia64?
Works great, thanks Gary! Ben, FYI - i'll file a bug against glibc for this. randolph In reference to a message from Gary Hade, dated Feb 25: > Randolph, > I believe this problem is due to a bug in /usr/lib/gcrt1.o > that was fixed by recent glibc changes to csu/gmon-start.c > (revs 1.13 and 1.14). > > Hope this helps. > > Gary > -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Bug#135651: libstdc++2.10-dev: upgrade fails "version GLIBC_2.2 not found
On Mon, Feb 25, 2002 at 09:39:13PM +, Philip Blundell wrote: > There is no point just trying to pin the blame on arbitrary packages. > The fact that libstdc++2.10-dev won't configure is a symptom of the > problem, not the cause. I don't consider "package that failed install" arbitrary. > > > > First significant bug is: > > > > > > > > Preparing to replace libstdc++2.10-dev 1:2.95.2-13 (using > > > > .../libstdc++2.10-dev_1%3a2.95.4-1_i386.deb) ... > > > > perl: /lib/libc.so.6: version `GLIBC_2.2' not found (required by > > > > /lib/libdb.so.3) > > It's fairly clear that this failure is caused by incompatible versions > of libdb2 and libc6 having been installed. And, sure enough, a few > lines higher up in your log you will see: > > Unpacking replacement libdb2-dev ... > Replacing files in old package libc6-dev ... > Preparing to replace libdb2-util 2:2.4.14-2.7.7.1.c (using > .../libdb2-util_2%3a2.7.7.0-3.1_i386.deb) ... > Unpacking replacement libdb2-util ... > Preparing to replace libdb2 2:2.4.14-2.7.7.1.c (using > .../libdb2_2%3a2.7.7.0-3.1_i386.deb) ... > Unpacking replacement libdb2 ... > Replacing files in old package libc6 ... > > I suggest you try reassigning the bug to libdb2. > > p. > The other lines wern't errors, and if you require the package to be configured before your package can be configured you need a pre-depend rather than a depend. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Bug#135651: libstdc++2.10-dev: upgrade fails "version GLIBC_2.2 not found
On Mon, 2002-02-25 at 21:51, Blars Blarson wrote: > On Mon, Feb 25, 2002 at 09:39:13PM +, Philip Blundell wrote: > > There is no point just trying to pin the blame on arbitrary packages. > > The fact that libstdc++2.10-dev won't configure is a symptom of the > > problem, not the cause. > > I don't consider "package that failed install" arbitrary. Once you have unpacked an incompatible libdb2, Perl is broken and all packages will fail to install. It is just by chance that libstdc++2.10-dev was the one that apt tried to install next. As I said before, the libstdc++2.10-dev failure was a symptom of the problem, not the cause. > > > > > First significant bug is: > > > > > > > > > > Preparing to replace libstdc++2.10-dev 1:2.95.2-13 (using > > > > > .../libstdc++2.10-dev_1%3a2.95.4-1_i386.deb) ... > > > > > perl: /lib/libc.so.6: version `GLIBC_2.2' not found (required by > > > > > /lib/libdb.so.3) > > > > It's fairly clear that this failure is caused by incompatible versions > > of libdb2 and libc6 having been installed. And, sure enough, a few > > lines higher up in your log you will see: > > > > Unpacking replacement libdb2-dev ... > > Replacing files in old package libc6-dev ... > > Preparing to replace libdb2-util 2:2.4.14-2.7.7.1.c (using > > .../libdb2-util_2%3a2.7.7.0-3.1_i386.deb) ... > > Unpacking replacement libdb2-util ... > > Preparing to replace libdb2 2:2.4.14-2.7.7.1.c (using > > .../libdb2_2%3a2.7.7.0-3.1_i386.deb) ... > > Unpacking replacement libdb2 ... > > Replacing files in old package libc6 ... > > > > I suggest you try reassigning the bug to libdb2. > > > > p. > > > > The other lines wern't errors, and if you require the package to be > configured before your package can be configured you need a pre-depend > rather than a depend. Right on. So, go file a bug on libdb2 to that effect. p.
Processed: 135651 goes to libdb2
Processing commands for [EMAIL PROTECTED]: > retitle 135651 libstdc++2.10-dev mainainter blames libdb2 for failed install Bug#135651: libstdc++2.10-dev: upgrade fails "version GLIBC_2.2 not found Changed Bug title. > reassign 135651 libdb2 Bug#135651: libstdc++2.10-dev mainainter blames libdb2 for failed install Bug reassigned from package `gcc-2.95' to `libdb2'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#135730: writeln radix control
> The "pc" compiler on Tru64 (formerly OSF/1 or Digital UNIX) has > radix control. NOTE: it is typed and works for negative values. > I get stuff like "-FFF" from -4095 but "EE6CD998" from 4000111000. > I've no idea how to get leading zeros on these. > >writeln(, 4095:2:16, ); Interesting feature, but there is one problem: The syntax is ambiguous. `WriteLn (4095:2:16)' can also mean: convert 4095 to real type (since integer is assignment-compatible to real) and write it with 16 digits. More generally, there's a number of useful extensions to the `Write[Ln]' formatting, including radix control, but also, e.g., left/right adjusted or centered output etc., and it seems impossible to stuff them all in the syntax. Therefore my current plans include a `FormatString' procedure that takes a format string which describes all the required formatting. So it's similar to C's `printf', but without its inherent type unsafeties. Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Bug#135727: buffer overflow (?) in writeln
> When I print floating-point numbers, I sometimes get garbage like this: > -:.00/+)))./(/0,,.0.-.0/,.-(e-15 Thanks for the report. However, I'm not quite sure of the GPC version you have (`gpc -v') -- Debian's numbering scheme is a little peculiar ;-). I guess the following means 20011006: > Package: gpc-2.95 > Source: gcc-2.95 (2.95.4.ds6-0.011006) > Version: 1:2.95.4-0.011006 I've fixed some bugs WRT writing of real numbers that appeared on Alpha processors, and it's quite possible that one of those bugs was also responsible for what you see. So I'm afraid I can only tell you to wait for the next version (RSN ;-) and test it again. > writeln(, -0.0001e-10:w, ); > writeln(, -0.0001e-10:w:p, ); > writeln(, 0.0001e-10:w, ); > writeln(, 0.0001e-10:w:p, ); > > Feel free to include any of this code (above and/or below) in the > gpc test suite. You can have it under the 2-clause BSD license. Thanks. I'll do so, so I'll notice if the problem appears on any other platform. > BTW, the assembly output for this code appears to be terribly > inefficient. (only a minute of study though) Floating-point constants > seem to get loaded multiple times instead of being kept in registers. Well, that's really a backend issue, i.e. the GCC developers would have to deal with it. (If you can reproduce the same behaviour with C code, it might be worth sending it to them ...) > For your wishlist, have -Os turn the code below into a loop over > an array. Well, I could put it on the list, but I don't really think it will ever be implemented. After all, it takes quite a bit of effort to recognize that the statements are "similar" and can be combined. (I mean effort both for the compiler writers who are always short of time, and for the compiler, i.e. it would slow down compilations which probably many people would not appreciate too much.) It raises the question how similar the code must be -- if, say, every 5th statement is different, should the compiler automatically create an `if'? All in all I don't think the effort is worth the advantage. It seems much easier for the Pascal programmer to write an array if that's what he wants. OTOH, it's easier for the compiler to unroll a loop when optimizing for speed (though actually in this case, it wouldn't be worth it, since the `WriteLn' call overhead is much bigger than the loop iteration). Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
