Bug#364231: [parisc-linux] Re: Bug#364231: exception catching
Matthias Klose wrote: [should we drop parisc-linux?] John David Anglin writes: Er, no; we're talking about official Debian packages here, and the libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting in the double libgcc_s problem. Then, you must build *eveything* for hppa with gcc-4.1 or later. Unfortunately, there's an ABI break. Mixing libraries compiled with 4.0 or earlier with libraries compiled with 4.1 or later is just going to cause unnecessary problems. 3.3 uses libstdc++.so.5, so you avoid the double libgcc_s problem building GMP. However, you still have the ABI change affecting the passing and return of complex types. At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any other gcc libraries built with 4.1 or later need glibc built with 4.1 to function correctly because of the various complex functions in the math library. I think there's a dynamic loader bug here as well. I'm just guessing but I think the double libgcc_s problem causes a problem with the handling of .eh_frame data. Ok, coming back to the question of the system compiler on hppa for etch. Assuming that hppa does want to do that: - is glibc buildable with gcc-4.1 on hppa? Yes, and it seems to works nicely. People who want to try can fetch .deb from http://people.debian.org/~aurel32/hppa/ -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching
[should we drop parisc-linux?] John David Anglin writes: Er, no; we're talking about official Debian packages here, and the libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting in the double libgcc_s problem. Then, you must build *eveything* for hppa with gcc-4.1 or later. Unfortunately, there's an ABI break. Mixing libraries compiled with 4.0 or earlier with libraries compiled with 4.1 or later is just going to cause unnecessary problems. 3.3 uses libstdc++.so.5, so you avoid the double libgcc_s problem building GMP. However, you still have the ABI change affecting the passing and return of complex types. At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any other gcc libraries built with 4.1 or later need glibc built with 4.1 to function correctly because of the various complex functions in the math library. I think there's a dynamic loader bug here as well. I'm just guessing but I think the double libgcc_s problem causes a problem with the handling of .eh_frame data. Ok, coming back to the question of the system compiler on hppa for etch. Assuming that hppa does want to do that: - is glibc buildable with gcc-4.1 on hppa? - libstdc++6 would need to conflict with libgcc2, which seems to be doable, but then rules out g++-3.4 and g++-4.0 as a fallback solution, where g++-4.1 fails. - libgfortran did have a soname change, so nothing needs to be done. - is libffi hit by the ABI change as well? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching
Ok, coming back to the question of the system compiler on hppa for etch. Assuming that hppa does want to do that: - is glibc buildable with gcc-4.1 on hppa? As far as I know, there's no new problems using 4.1 instead of 4.0. See http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028894.html and test results for a gcc 4.2.0 build using this glibc build http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028918.html - libstdc++6 would need to conflict with libgcc2, which seems to be doable, but then rules out g++-3.4 and g++-4.0 as a fallback solution, where g++-4.1 fails. True. - is libffi hit by the ABI change as well? No. It's not affected because it doesn't support complex types. I have one libffi fix that's not yet in 4.2.0 that fixes the remaining Java testsuite failures. I haven't tested a backport to 4.1. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching
Er, no; we're talking about official Debian packages here, and the libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting in the double libgcc_s problem. Then, you must build *eveything* for hppa with gcc-4.1 or later. Unfortunately, there's an ABI break. Mixing libraries compiled with 4.0 or earlier with libraries compiled with 4.1 or later is just going to cause unnecessary problems. 3.3 uses libstdc++.so.5, so you avoid the double libgcc_s problem building GMP. However, you still have the ABI change affecting the passing and return of complex types. At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any other gcc libraries built with 4.1 or later need glibc built with 4.1 to function correctly because of the various complex functions in the math library. I think there's a dynamic loader bug here as well. I'm just guessing but I think the double libgcc_s problem causes a problem with the handling of .eh_frame data. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA
Is this acutally decided? Is it likely to happen soon, or should I build GMP with gcc 3.3 (which doesn't exhibit the problem) in the short term? For now, I suggest that you remove gcc-4.1 from your build system. Then, GMP should build fine with 4.0. You might have to reinstall 4.0. As far as I can tell, EH support breaks when two different versions of libgcc_s are linked into an application. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA
On Sun, Apr 30, 2006 at 06:53:03PM -0400, John David Anglin wrote: Is this acutally decided? Is it likely to happen soon, or should I build GMP with gcc 3.3 (which doesn't exhibit the problem) in the short term? For now, I suggest that you remove gcc-4.1 from your build system. Then, GMP should build fine with 4.0. You might have to reinstall 4.0. Er, no; we're talking about official Debian packages here, and the libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting in the double libgcc_s problem. So removing gcc-4.1 from his build system isn't an option unless we find a way to do this systemically for Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA
On Sat, Apr 22, 2006 at 11:22:20AM -0400, John David Anglin wrote: ... I recognized that this was going to cause pain, and brought the matter up for discussion on the parisc-linux list a few months ago. There wasn't much in the way of comments for or against. In the end, I decided it was probably better to make the change in 4.1 and let time smooth over the difficulties. You did and I still think it was the right choice. thanks, grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA
On Sat, Apr 22, 2006 at 10:00:04AM +0200, Matthias Klose wrote: $ ldd a.out libstdc++.so.6 =3D /usr/lib/libstdc++.so.6 (0x40575000) libm.so.6 =3D /lib/libm.so.6 (0x4046e000) libgcc_s.so.2 =3D /lib/libgcc_s.so.2 (0x40068000) libc.so.6 =3D /lib/libc.so.6 (0x4074b000) libgcc_s.so.4 =3D /lib/libgcc_s.so.4 (0x40015000) /lib/ld.so.1 (0x400e1000) We end up with both libgcc_s.so.2 and libgcc_s.so.4 linked. Is there a solution other than making gcc-4.1/g++-4.1 the default and rebuilding the libstdc++6 dependent packages with binary NMU's? I guess having gcc-4.0 link against libgcc4 is out of the question? Doing so is not a good idea, but it's only going to break numeric applications using complex numbers and possibly vectors. The calling conventions for passing complex values was changed between 4.0 and 4.1 when it was discovered that it didn't conform to the runtime documentation. Support for complex and vector objects was added to GCC some time ago. However noone noticed that these values weren't being passed correctly... The change affects the routines __muldc3, __mulsc3, __divdc3 and __divsc3 in libgcc_s. It also affects any package/library using complex numbers, including glibc since the registers used for passing the first few arguments and the return value have changed. Particularly, complex floats are no longer passed in the floating registers. I think the approach suggested by Matthias is ultimately the only viable solution but the impact is broader than the libstdc++6 dependent packages. The situation is similar to that when DWARF EH support was introduced. The only other option that I can see is to delay 4.1. However, I would like 4.1 to become the default. For the most part, the passing of complex values in 4.0 and earlier is internally self-consistent (there's a minor incompatibility between PA 1.0 code and PA 1.1 code due to the fact that the left and right halves of floating-point registers are not independently accessible when generating PA 1.0 code). I recognized that this was going to cause pain, and brought the matter up for discussion on the parisc-linux list a few months ago. There wasn't much in the way of comments for or against. In the end, I decided it was probably better to make the change in 4.1 and let time smooth over the difficulties. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA
[EMAIL PROTECTED]:~/gmp-4.2.dfsg/tests/cxx$ g++ -Wall test-throw.cc ./a.out /usr/bin/ld: warning: libgcc_s.so.4, needed by /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so, may conflict with libgcc_s.so.2 I'm puzzled about this. It seems like libstdc++ for GCC 4.0.3 was built using GCC 4.1 or latter. In my 4.0.3 build, I see: [EMAIL PROTECTED]:~/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src/.libs$ ldd libstdc++.so libm.so.6 = /lib/libm.so.6 (0x40643000) libgcc_s.so.2 = /lib/libgcc_s.so.2 (0x4034a000) libc.so.6 = /lib/libc.so.6 (0x40a57000) /lib/ld.so.1 (0x41252000) But: [EMAIL PROTECTED]:~/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src/.libs$ ldd /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so libm.so.6 = /lib/libm.so.6 (0x40243000) libgcc_s.so.4 = /lib/libgcc_s.so.4 (0x40746000) libc.so.6 = /lib/libc.so.6 (0x40a57000) /lib/ld.so.1 (0x41252000) You need to build 4.0.3 and associated libraries with 4.0.3. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA
John David Anglin writes: [EMAIL PROTECTED]:~/gmp-4.2.dfsg/tests/cxx$ g++ -Wall test-throw.cc ./a.out /usr/bin/ld: warning: libgcc_s.so.4, needed by /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so, may conflict with libgcc_s.so.2 I'm puzzled about this. It seems like libstdc++ for GCC 4.0.3 was built using GCC 4.1 or latter. In my 4.0.3 build, I see: [EMAIL PROTECTED]:~/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src/.libs$ ldd libstdc++.so libm.so.6 = /lib/libm.so.6 (0x40643000) libgcc_s.so.2 = /lib/libgcc_s.so.2 (0x4034a000) libc.so.6 = /lib/libc.so.6 (0x40a57000) /lib/ld.so.1 (0x41252000) But: [EMAIL PROTECTED]:~/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src/.libs$ ldd /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so libm.so.6 = /lib/libm.so.6 (0x40243000) libgcc_s.so.4 = /lib/libgcc_s.so.4 (0x40746000) libc.so.6 = /lib/libc.so.6 (0x40a57000) /lib/ld.so.1 (0x41252000) You need to build 4.0.3 and associated libraries with 4.0.3. Yes, we do, but $ ls -l /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so lrwxr-xr-x 1 root root 23 Apr 6 02:08 /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so - ../../../libstdc++.so.6 we can only have one libstdc++.so.6 installed. that's currently the library from 4.1. So maybe we need to bump the soversion of libstdc++ on hppa? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA
Yes, we do, but $ ls -l /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so lrwxr-xr-x 1 root root 23 Apr 6 02:08 /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so - ../../../libstdc++.so.6 Oh, I was thinking there were separate libraries for each GCC version. I've had to live with this for some time using hpux. we can only have one libstdc++.so.6 installed. that's currently the library from 4.1. So maybe we need to bump the soversion of libstdc++ on hppa? To me, that seems too complicated. It's not just libstdc++.so.6 but potentially every shared library built with 4.1 or later needs a bump. The simplest approach is to make GCC 4.1 the default and remove 4.0 and earlier. Then, gradually rebuild everthing with 4.1. There have been reports on the gcc list that this has been reasonably successful. I imagine that some will complain about losing their favorite GCC version. The issues with C are less severe because of the libgcc_s version bump. Old versions will generate code that's incompatible with the complex math routines in libc6 but they should otherwise work. I think for kernel building it's useful to keep old versions, but not for much else. Thus, the compromise may be to keep old versions of C and drop all the other languages. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
