Re: 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]
Re: 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]
Re: 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]
