Bug#204805: Intel have reproduced this 'bug'
Hi Masanori, #204805 is fixed now. #256770 is a new bug. But the problem may not be with the Intel compiler. Why are symbols multiply defined in libc.a?? It seems a mistake. The Intel compiler works on RedHat and SuSE. Also, you can download the compiler for free, from this website: http://developer.intel.com/software/products/compilers/clin/noncom.htm (but you must register). Good luck! Duraid GOTO Masanori wrote: At Tue, 12 Aug 2003 06:40:11 +1000, Duraid Madina wrote: And they say that 'this problem is due to our compiler not supporting glibc 2.3 yet.' A fix is in the works, apparently. #204805 is reported in 2.3.2, but now we have 2.3.2.ds1. Is this bug still alive? BTW, there's two bugs about intel C/C++: #204805, #256770. Both bugs are reported by you. I guess the newer version fix #204805, but it's still broken (#256770). I wonder why debian glibc obstruct compilation with intel C/C++. Is it designed only for RedHat's glibc? Commercial applications are difficult to check because we cannot get easily. I know the speed difference between gcc and intel cc. It's currently different significantly in the high performance numerical computation. So it's valuable to investigate on Debian IA-64. Duraid, please check this bug more. Regards, -- gotom
Bug#204805: Intel have reproduced this 'bug'
Hi Masanori, #204805 is fixed now. #256770 is a new bug. But the problem may not be with the Intel compiler. Why are symbols multiply defined in libc.a?? It seems a mistake. The Intel compiler works on RedHat and SuSE. Also, you can download the compiler for free, from this website: http://developer.intel.com/software/products/compilers/clin/noncom.htm (but you must register). Good luck! Duraid GOTO Masanori wrote: At Tue, 12 Aug 2003 06:40:11 +1000, Duraid Madina wrote: And they say that 'this problem is due to our compiler not supporting glibc 2.3 yet.' A fix is in the works, apparently. #204805 is reported in 2.3.2, but now we have 2.3.2.ds1. Is this bug still alive? BTW, there's two bugs about intel C/C++: #204805, #256770. Both bugs are reported by you. I guess the newer version fix #204805, but it's still broken (#256770). I wonder why debian glibc obstruct compilation with intel C/C++. Is it designed only for RedHat's glibc? Commercial applications are difficult to check because we cannot get easily. I know the speed difference between gcc and intel cc. It's currently different significantly in the high performance numerical computation. So it's valuable to investigate on Debian IA-64. Duraid, please check this bug more. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#256770: libc6.1-dev: multiple definitions in libc.a (lc-ctype.o), breaks Intel compiler
Package: libc6.1-dev Version: 2.3.2.ds1-13.0.1 Severity: normal Tags: experimental Hi there, libc.a has objects with have multiply defined symbols. Is this the intention? I hope not, because it breaks the Intel C compiler's interprocedural optimization. Write a simple C program, try to build it with 'icc -ipo ' and you will see messages like: libc.a(read.o) : multiple definition of '__syscall_error_3' libc.a(open.o): first defined here libc.a(llseek.o) : multiple definition of '__syscall_error_3' libc.a(open.o): first defined here libc.a(write.o) : multiple definition of '__syscall_error_3' libc.a(open.o): first defined here libc.a(lc-ctype.o) : multiple definition of '_nl_postload_ctype' libc.a(lc-ctype.o): first defined here libc.a(lc-ctype.o) : multiple definition of '_nl_current_LC_CTYPE' libc.a(lc-ctype.o): first defined here libc.a(lc-ctype.o) : multiple definition of '_nl_postload_ctype' libc.a(lc-ctype.o): first defined here ... This looks bad. Not sure exactly when the regression occurred, but it hasn't been _that_ long (less than two or three months, I think). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: ia64 Kernel: Linux 2.6.5-rc2 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6.1-dev depends on: ii libc6.1 2.3.2.ds1-13.0.1GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-16 Linux Kernel Headers for developme -- no debconf information
Bug#256770: libc6.1-dev: multiple definitions in libc.a (lc-ctype.o), breaks Intel compiler
Package: libc6.1-dev Version: 2.3.2.ds1-13.0.1 Severity: normal Tags: experimental Hi there, libc.a has objects with have multiply defined symbols. Is this the intention? I hope not, because it breaks the Intel C compiler's interprocedural optimization. Write a simple C program, try to build it with 'icc -ipo ' and you will see messages like: libc.a(read.o) : multiple definition of '__syscall_error_3' libc.a(open.o): first defined here libc.a(llseek.o) : multiple definition of '__syscall_error_3' libc.a(open.o): first defined here libc.a(write.o) : multiple definition of '__syscall_error_3' libc.a(open.o): first defined here libc.a(lc-ctype.o) : multiple definition of '_nl_postload_ctype' libc.a(lc-ctype.o): first defined here libc.a(lc-ctype.o) : multiple definition of '_nl_current_LC_CTYPE' libc.a(lc-ctype.o): first defined here libc.a(lc-ctype.o) : multiple definition of '_nl_postload_ctype' libc.a(lc-ctype.o): first defined here ... This looks bad. Not sure exactly when the regression occurred, but it hasn't been _that_ long (less than two or three months, I think). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: ia64 Kernel: Linux 2.6.5-rc2 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6.1-dev depends on: ii libc6.1 2.3.2.ds1-13.0.1GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-16 Linux Kernel Headers for developme -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#216466: libc6.1 breaks software far and wide
Linux freestyle 2.6.0-test8 #1 SMP Sun Oct 19 08:27:47 EST 2003 ia64 GNU/Linux Daniel Jacobowitz wrote: What kernel? On Wed, Oct 29, 2003 at 10:01:14AM +1100, Duraid Madina wrote: I tries 2.3.2ds1-7 but I don't get 'java' working fine - it segfaults, as before. bugger :( Duraid Daniel Jacobowitz wrote: severity 216466 normal retitle 216466 glibc: Problems with ia64 applications thanks On Mon, Oct 20, 2003 at 09:28:53PM -0400, Daniel Jacobowitz wrote: To reproduce this, all you should have to do is: 1) download http://download2.bea.com/pub/jrockit/81/jrockit-8.1sp1-j2se1.4.1-linux64.bin 2) run (to install) 3) type 'java' Hopefully you can then tell if it's the JVM at fault, or a bug in glibc. Sorry I'm not being very helpful! I can't test ia64. Someone else will have to. With 2.3.2.ds1-7, I get: merulo% ./ld-2.3.2.so --library-path `pwd` ~/jrockit-8.1sp1-j2se1.4.1-linux64.bin Extracting 0%100% Unable to instantiate GUI, defaulting to console mode. = BEGIN DUMP = JRockit context dump produced asynchronously on Mon Oct 27 21:57:10 2003 If you see this dump, please send it, along with as much information as you can on your system setup and the program you were running, to [EMAIL PROTECTED] Please include the file jrockit.30808.dump from the current directory in the bug report. Thank you. i.e. it crashes, but after going a little further. It's well into the JVM at this point. It deletes its own core dump (what a bug...) so I can't find out more. Under strace, it installs OK. This looks like a clear-cut timing problem with their JVM; may want to report it to them. 'java' works fine and produces a usage message. You may want to try -7... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#216466: libc6.1 breaks software far and wide
I tries 2.3.2ds1-7 but I don't get 'java' working fine - it segfaults, as before. bugger :( Duraid Daniel Jacobowitz wrote: severity 216466 normal retitle 216466 glibc: Problems with ia64 applications thanks On Mon, Oct 20, 2003 at 09:28:53PM -0400, Daniel Jacobowitz wrote: To reproduce this, all you should have to do is: 1) download http://download2.bea.com/pub/jrockit/81/jrockit-8.1sp1-j2se1.4.1-linux64.bin 2) run (to install) 3) type 'java' Hopefully you can then tell if it's the JVM at fault, or a bug in glibc. Sorry I'm not being very helpful! I can't test ia64. Someone else will have to. With 2.3.2.ds1-7, I get: merulo% ./ld-2.3.2.so --library-path `pwd` ~/jrockit-8.1sp1-j2se1.4.1-linux64.bin Extracting 0%100% Unable to instantiate GUI, defaulting to console mode. = BEGIN DUMP = JRockit context dump produced asynchronously on Mon Oct 27 21:57:10 2003 If you see this dump, please send it, along with as much information as you can on your system setup and the program you were running, to [EMAIL PROTECTED] Please include the file jrockit.30808.dump from the current directory in the bug report. Thank you. i.e. it crashes, but after going a little further. It's well into the JVM at this point. It deletes its own core dump (what a bug...) so I can't find out more. Under strace, it installs OK. This looks like a clear-cut timing problem with their JVM; may want to report it to them. 'java' works fine and produces a usage message. You may want to try -7... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#216466: libc6.1 breaks software far and wide
Daniel Jacobowitz wrote: You didn't say which version of the Intel compiler broke. I'm told that this compiler has known issues with recent versions of glibc so I'm inclined to suspect that the compiler is at fault. (%:~)- ecc -V Intel(R) C++ Itanium(R) Compiler for Itanium(R)-based applications Version 7.1, Build 20030924 Copyright (C) 1985-2003 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY GNU ld version 2.14.90.0.6 20030820 Debian GNU/Linux Supported emulations: elf64_ia64 Intel claims this version supports glibc 2.3.2, but who knows. JVMs are famous for abusing glibc interfaces, also. The thing is, in both these cases (compiler+jvm) they're not actually _doing_ much: they segfault immediately, or very close to it. X is worrisome. Can you reproduce this without using a beta CVS version of XFree86? No, because there's only so far back I can go with XF86 before it just doesn't work on my platform. However, I can say that the bug also exists in a CVS version from about 3 months ago. Or any less monolithic application? You haven't given us much to work with. To reproduce this, all you should have to do is: 1) download http://download2.bea.com/pub/jrockit/81/jrockit-8.1sp1-j2se1.4.1-linux64.bin 2) run (to install) 3) type 'java' Hopefully you can then tell if it's the JVM at fault, or a bug in glibc. Sorry I'm not being very helpful! Duraid
Bug#216466: libc6.1 breaks software far and wide
Daniel Jacobowitz wrote: You didn't say which version of the Intel compiler broke. I'm told that this compiler has known issues with recent versions of glibc so I'm inclined to suspect that the compiler is at fault. (%:~)- ecc -V Intel(R) C++ Itanium(R) Compiler for Itanium(R)-based applications Version 7.1, Build 20030924 Copyright (C) 1985-2003 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY GNU ld version 2.14.90.0.6 20030820 Debian GNU/Linux Supported emulations: elf64_ia64 Intel claims this version supports glibc 2.3.2, but who knows. JVMs are famous for abusing glibc interfaces, also. The thing is, in both these cases (compiler+jvm) they're not actually _doing_ much: they segfault immediately, or very close to it. X is worrisome. Can you reproduce this without using a beta CVS version of XFree86? No, because there's only so far back I can go with XF86 before it just doesn't work on my platform. However, I can say that the bug also exists in a CVS version from about 3 months ago. Or any less monolithic application? You haven't given us much to work with. To reproduce this, all you should have to do is: 1) download http://download2.bea.com/pub/jrockit/81/jrockit-8.1sp1-j2se1.4.1-linux64.bin 2) run (to install) 3) type 'java' Hopefully you can then tell if it's the JVM at fault, or a bug in glibc. Sorry I'm not being very helpful! Duraid -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#216466: libc6.1 breaks software far and wide
No, it doesn't. So I guess it's broken for other reasons. :( Duraid Colin Watson wrote: On Sun, Oct 19, 2003 at 01:21:01PM +1000, Duraid Madina wrote: Well, I can confirm that 2.3.2-8 also works. It's just 2.3.2.ds1-5 that's brain-dead. Does setting LD_ASSUME_KERNEL=2.4.1 in the environment make said software work again? That would distinguish between NPTL causing problems and this version being broken for other reasons. Cheers,
Bug#216466: libc6.1 breaks software far and wide
No, it doesn't. So I guess it's broken for other reasons. :( Duraid Colin Watson wrote: On Sun, Oct 19, 2003 at 01:21:01PM +1000, Duraid Madina wrote: Well, I can confirm that 2.3.2-8 also works. It's just 2.3.2.ds1-5 that's brain-dead. Does setting LD_ASSUME_KERNEL=2.4.1 in the environment make said software work again? That would distinguish between NPTL causing problems and this version being broken for other reasons. Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#216466: libc6.1 breaks software far and wide
Well, I can confirm that 2.3.2-8 also works. It's just 2.3.2.ds1-5 that's brain-dead. Duraid Jeff Bailey wrote: tags 216466 -sid tags 216466 +experimental thanks control, over and out. I've just double checked, and 2.3.2-8 is in unstable. 2.3.2.ds1-5 is in experimental. I've now recovered from the mild heart attack. =) Thanks for the bug report, though.
Bug#216466: libc6.1 breaks software far and wide
Oh geez, sorry to do that to you :( Don't worry, already got the paper bag on. Duraid Jeff Bailey wrote: tags 216466 -sid tags 216466 +experimental thanks control, over and out. I've just double checked, and 2.3.2-8 is in unstable. 2.3.2.ds1-5 is in experimental. I've now recovered from the mild heart attack. =) Thanks for the bug report, though. On Sun, Oct 19, 2003 at 10:46:03AM +1000, Duraid Madina wrote: Package: libc6.1 Version: 2.3.2-7 Severity: critical Tags: sid Justification: breaks unrelated software The current libc6.1 in unstable, (2.3.2.ds1-5) breaks various pieces of software, such as: XFree86 (4.3.99.14) BEA's JVM (BEA WebLogic JRockit(R) Virtual Machine (build 8.1sp1-1.4.1-viking-Load8-linux64-stheng03-20030709-1550, Native Threads, Generational Concurrent Garbage Collector) the Intel C/C++ compiler Some of this stuff is binary-only, some of it is built from source. Whatever the case, it doesn't matter, this libc _breaks stuff_. Here's an example stack trace of XFree86 dying: Program received signal SIGSEGV, Segmentation fault. 0x2018e6e1 in __strtoll_internal () from /lib/libc.so.6.1 (gdb) where #0 0x2018e6e1 in __strtoll_internal () from /lib/libc.so.6.1 #1 0x400a7a30 in xf86strtol () #2 0x24644a40 in NvRmAllocDevice () from /home/duraid/XF43/lib/modules/extensions/libglx.so #3 0x2463bec0 in __nvsym30454 () from /home/duraid/XF43/lib/modules/extensions/libglx.so #4 0x400a7a30 in xf86strtol () #5 0xc389 in ?? () #6 0x400a7a30 in xf86strtol () #7 0x600469f8 in __JCR_LIST__ () #8 0x400a7a30 in xf86strtol () #9 0x6001cc20 in indexForBitsPerPixel () #10 0x400a7a30 in xf86strtol () #11 0x600604c0 in dixScreenOrigins () #12 0x400a7a30 in xf86strtol () #13 0x in ?? () (gdb) Reverting libc6.1 to 2.3.2-7 makes everything work like a charm once again. I hope you can track this one down, it's hard to do development work without C, java or X! ;( Duraid -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux freestyle 2.6.0-test8 #1 SMP Sun Oct 19 08:27:47 EST 2003 ia64 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6.1 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#216466: libc6.1 breaks software far and wide
Well, I can confirm that 2.3.2-8 also works. It's just 2.3.2.ds1-5 that's brain-dead. Duraid Jeff Bailey wrote: tags 216466 -sid tags 216466 +experimental thanks control, over and out. I've just double checked, and 2.3.2-8 is in unstable. 2.3.2.ds1-5 is in experimental. I've now recovered from the mild heart attack. =) Thanks for the bug report, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#216466: libc6.1 breaks software far and wide
Oh geez, sorry to do that to you :( Don't worry, already got the paper bag on. Duraid Jeff Bailey wrote: tags 216466 -sid tags 216466 +experimental thanks control, over and out. I've just double checked, and 2.3.2-8 is in unstable. 2.3.2.ds1-5 is in experimental. I've now recovered from the mild heart attack. =) Thanks for the bug report, though. On Sun, Oct 19, 2003 at 10:46:03AM +1000, Duraid Madina wrote: Package: libc6.1 Version: 2.3.2-7 Severity: critical Tags: sid Justification: breaks unrelated software The current libc6.1 in unstable, (2.3.2.ds1-5) breaks various pieces of software, such as: XFree86 (4.3.99.14) BEA's JVM (BEA WebLogic JRockit(R) Virtual Machine (build 8.1sp1-1.4.1-viking-Load8-linux64-stheng03-20030709-1550, Native Threads, Generational Concurrent Garbage Collector) the Intel C/C++ compiler Some of this stuff is binary-only, some of it is built from source. Whatever the case, it doesn't matter, this libc _breaks stuff_. Here's an example stack trace of XFree86 dying: Program received signal SIGSEGV, Segmentation fault. 0x2018e6e1 in __strtoll_internal () from /lib/libc.so.6.1 (gdb) where #0 0x2018e6e1 in __strtoll_internal () from /lib/libc.so.6.1 #1 0x400a7a30 in xf86strtol () #2 0x24644a40 in NvRmAllocDevice () from /home/duraid/XF43/lib/modules/extensions/libglx.so #3 0x2463bec0 in __nvsym30454 () from /home/duraid/XF43/lib/modules/extensions/libglx.so #4 0x400a7a30 in xf86strtol () #5 0xc389 in ?? () #6 0x400a7a30 in xf86strtol () #7 0x600469f8 in __JCR_LIST__ () #8 0x400a7a30 in xf86strtol () #9 0x6001cc20 in indexForBitsPerPixel () #10 0x400a7a30 in xf86strtol () #11 0x600604c0 in dixScreenOrigins () #12 0x400a7a30 in xf86strtol () #13 0x in ?? () (gdb) Reverting libc6.1 to 2.3.2-7 makes everything work like a charm once again. I hope you can track this one down, it's hard to do development work without C, java or X! ;( Duraid -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux freestyle 2.6.0-test8 #1 SMP Sun Oct 19 08:27:47 EST 2003 ia64 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6.1 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#216466: libc6.1 breaks software far and wide
Package: libc6.1 Version: 2.3.2-7 Severity: critical Tags: sid Justification: breaks unrelated software The current libc6.1 in unstable, (2.3.2.ds1-5) breaks various pieces of software, such as: XFree86 (4.3.99.14) BEA's JVM (BEA WebLogic JRockit(R) Virtual Machine (build 8.1sp1-1.4.1-viking-Load8-linux64-stheng03-20030709-1550, Native Threads, Generational Concurrent Garbage Collector) the Intel C/C++ compiler Some of this stuff is binary-only, some of it is built from source. Whatever the case, it doesn't matter, this libc _breaks stuff_. Here's an example stack trace of XFree86 dying: Program received signal SIGSEGV, Segmentation fault. 0x2018e6e1 in __strtoll_internal () from /lib/libc.so.6.1 (gdb) where #0 0x2018e6e1 in __strtoll_internal () from /lib/libc.so.6.1 #1 0x400a7a30 in xf86strtol () #2 0x24644a40 in NvRmAllocDevice () from /home/duraid/XF43/lib/modules/extensions/libglx.so #3 0x2463bec0 in __nvsym30454 () from /home/duraid/XF43/lib/modules/extensions/libglx.so #4 0x400a7a30 in xf86strtol () #5 0xc389 in ?? () #6 0x400a7a30 in xf86strtol () #7 0x600469f8 in __JCR_LIST__ () #8 0x400a7a30 in xf86strtol () #9 0x6001cc20 in indexForBitsPerPixel () #10 0x400a7a30 in xf86strtol () #11 0x600604c0 in dixScreenOrigins () #12 0x400a7a30 in xf86strtol () #13 0x in ?? () (gdb) Reverting libc6.1 to 2.3.2-7 makes everything work like a charm once again. I hope you can track this one down, it's hard to do development work without C, java or X! ;( Duraid -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux freestyle 2.6.0-test8 #1 SMP Sun Oct 19 08:27:47 EST 2003 ia64 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6.1 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information
Bug#216466: libc6.1 breaks software far and wide
Package: libc6.1 Version: 2.3.2-7 Severity: critical Tags: sid Justification: breaks unrelated software The current libc6.1 in unstable, (2.3.2.ds1-5) breaks various pieces of software, such as: XFree86 (4.3.99.14) BEA's JVM (BEA WebLogic JRockit(R) Virtual Machine (build 8.1sp1-1.4.1-viking-Load8-linux64-stheng03-20030709-1550, Native Threads, Generational Concurrent Garbage Collector) the Intel C/C++ compiler Some of this stuff is binary-only, some of it is built from source. Whatever the case, it doesn't matter, this libc _breaks stuff_. Here's an example stack trace of XFree86 dying: Program received signal SIGSEGV, Segmentation fault. 0x2018e6e1 in __strtoll_internal () from /lib/libc.so.6.1 (gdb) where #0 0x2018e6e1 in __strtoll_internal () from /lib/libc.so.6.1 #1 0x400a7a30 in xf86strtol () #2 0x24644a40 in NvRmAllocDevice () from /home/duraid/XF43/lib/modules/extensions/libglx.so #3 0x2463bec0 in __nvsym30454 () from /home/duraid/XF43/lib/modules/extensions/libglx.so #4 0x400a7a30 in xf86strtol () #5 0xc389 in ?? () #6 0x400a7a30 in xf86strtol () #7 0x600469f8 in __JCR_LIST__ () #8 0x400a7a30 in xf86strtol () #9 0x6001cc20 in indexForBitsPerPixel () #10 0x400a7a30 in xf86strtol () #11 0x600604c0 in dixScreenOrigins () #12 0x400a7a30 in xf86strtol () #13 0x in ?? () (gdb) Reverting libc6.1 to 2.3.2-7 makes everything work like a charm once again. I hope you can track this one down, it's hard to do development work without C, java or X! ;( Duraid -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux freestyle 2.6.0-test8 #1 SMP Sun Oct 19 08:27:47 EST 2003 ia64 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6.1 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204805: Intel have reproduced this 'bug'
And they say that 'this problem is due to our compiler not supporting glibc 2.3 yet.' A fix is in the works, apparently. Duraid -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204805: libc6.1-dev: new libc breaks intel C/C++ compiler
Package: libc6.1-dev Version: 2.3.2-2 Severity: normal Tags: sid Previously, I could run ecc. Now, I get: [EMAIL PROTECTED]:~$ ecc /usr/lib/crt1.o(.text+0x41): In function start': : undefined reference to ain' /usr/lib/libc_nonshared.a(elf-init.oS)(.text+0x31): In function _libc_csu_init': : undefined reference to _init_array_start' /usr/lib/libc_nonshared.a(elf-init.oS)(.text+0x32): In function _libc_csu_init': : undefined reference to _init_array_end' /usr/lib/libc_nonshared.a(elf-init.oS)(.text+0x40): In function _libc_csu_init': : undefined reference to _init_array_start' /usr/lib/libc_nonshared.a(elf-init.oS)(.text+0x41): In function _libc_csu_init': : undefined reference to _init_array_end' /usr/lib/libc_nonshared.a(elf-init.oS)(.text+0xd1): In function _libc_csu_fini': : undefined reference to _fini_array_start' /usr/lib/libc_nonshared.a(elf-init.oS)(.text+0xd2): In function _libc_csu_fini': : undefined reference to _fini_array_end' /usr/lib/libc_nonshared.a(elf-init.oS)(.text+0xf0): In function _libc_csu_fini': : undefined reference to _fini_array_start' /usr/lib/libc_nonshared.a(elf-init.oS)(.text+0xf1): In function _libc_csu_fini': : undefined reference to _fini_array_end' [EMAIL PROTECTED]:~$ -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux freestyle 2.6.0-test2 #4 SMP Sat Aug 2 11:05:23 EST 2003 ia64 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6.1-dev depends on: ii libc6.1 2.3.2-2GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
