Re: [parisc-linux] glibc is broken because of gcc
On Thu, Jul 05, 2007 at 11:18:05AM -0400, John David Anglin wrote: Could you do glibc builds with the gcc trunk before and after the change? It's best to base the PR on an unmodified version of gcc. The test with the gcc-trunk (Main 4.3.0 head) shows the same error at the same place. Ok, it would be useful to file a gcc PR to start. However, it's not clear that gcc is a fault. It may be that glibc isn't using the visibility attribute correctly for this symbol (i.e., hiding a symbol that is externally referenced). The patch below based on the m68k version of sysdep-cancel.h fixes the problem. 2007-07-10 Aurelien Jarno [EMAIL PROTECTED] * sysdeps/unix/sysv/linux/hppa/linuxthreads/sysdep-cancel.h: (__local_multiple_threads): Declare as hidden only in libc and in libpthread. Index: ports/sysdeps/unix/sysv/linux/hppa/linuxthreads/sysdep-cancel.h === --- ports/sysdeps/unix/sysv/linux/hppa/linuxthreads/sysdep-cancel.h.orig +++ ports/sysdeps/unix/sysv/linux/hppa/linuxthreads/sysdep-cancel.h @@ -206,7 +206,11 @@ # endif # ifndef __ASSEMBLER__ - extern int __local_multiple_threads attribute_hidden; +# if !defined NOT_IN_libc || defined IS_IN_libpthread +extern int __local_multiple_threads attribute_hidden; +# else +extern int __local_multiple_threads; +# endif # define SINGLE_THREAD_P __builtin_expect (__local_multiple_threads == 0, 1) # else /* This ALT version requires newer kernel support */ -- .''`. 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: [parisc-linux] glibc is broken because of gcc
On the other hand, the LinuxThreads build on other architectures are still fine even with the latest gcc in Debian. Is the __librt_multiple_threads symbol defined, undefined or not used in librt.so? On both hppa and m68k I get: DO *UND* 0004 GLIBC_PRIVATE __librt_multiple_threads So, it would seem m68k is also broken if the definition in libc-2.5.so is hidden. 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]
Re: [parisc-linux] glibc is broken because of gcc
On Mon, Jul 02, 2007 at 09:58:45PM -0400, John David Anglin wrote: [snip] Looking at gcc PR 20218, it's clear that there are some very subtle issues here. So, it's not clear to me where the problem lies. It could be in glibc (hppa sysdep-cancel.h), binutils or gcc. The handling of the visibility attribute was broken prior to HJL's change, so it could have exposed bugs in other packages. Because of this, it was a mistake for Debian to backport this change. The change is only in the unreleased gcc trunk. Since the problem was introduced by a gcc change, I'd start with a gcc PR and mention the patch that introduced the regression. Could you do glibc builds with the gcc trunk before and after the change? It's best to base the PR on an unmodified version of gcc. The test with the gcc-trunk (Main 4.3.0 head) shows the same error at the same place. By the way, did I mention that the problem is not present if nptl is enabled ? It would help to know the exact details of the linker command that fails, the assembler code generated for mq_timedreceive, and the __librt_multiple_threads symbols in __librt_multiple_threads librt.so. Did you had a look at the info I sent you (see my previous message) ? What do you think of this ? Seb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc is broken because of gcc
On 05/07/07, John David Anglin [EMAIL PROTECTED] wrote: Could you do glibc builds with the gcc trunk before and after the change? It's best to base the PR on an unmodified version of gcc. The test with the gcc-trunk (Main 4.3.0 head) shows the same error at the same place. Ok, it would be useful to file a gcc PR to start. However, it's not clear that gcc is a fault. It may be that glibc isn't using the visibility attribute correctly for this symbol (i.e., hiding a symbol that is externally referenced). You could try building glibc with the attribute removed. This might be somewhat hppa specific because of the nptl issue. As long as LinuxThreads isn't built, this problem doesn't come up. It seems very likely that it's a glibc problem, then. The Ubuntu builds are NPTL-only and don't show this problem. -- Jeff Bailey - http://www.raspberryginger.com/jbailey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc is broken because of gcc
Could you do glibc builds with the gcc trunk before and after the change? It's best to base the PR on an unmodified version of gcc. The test with the gcc-trunk (Main 4.3.0 head) shows the same error at the same place. Ok, it would be useful to file a gcc PR to start. However, it's not clear that gcc is a fault. It may be that glibc isn't using the visibility attribute correctly for this symbol (i.e., hiding a symbol that is externally referenced). You could try building glibc with the attribute removed. This might be somewhat hppa specific because of the nptl issue. It would help to know the exact details of the linker command that fails, the assembler code generated for mq_timedreceive, and the __librt_multiple_threads symbols in __librt_multiple_threads librt.so. Did you had a look at the info I sent you (see my previous message) ? I looked at it briefly but don't have a comment at the moment. I was hoping to figure out which package is responsible for this problem. 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]
Re: [parisc-linux] glibc is broken because of gcc
Jeff Bailey a écrit : On 05/07/07, John David Anglin [EMAIL PROTECTED] wrote: Could you do glibc builds with the gcc trunk before and after the change? It's best to base the PR on an unmodified version of gcc. The test with the gcc-trunk (Main 4.3.0 head) shows the same error at the same place. Ok, it would be useful to file a gcc PR to start. However, it's not clear that gcc is a fault. It may be that glibc isn't using the visibility attribute correctly for this symbol (i.e., hiding a symbol that is externally referenced). You could try building glibc with the attribute removed. This might be somewhat hppa specific because of the nptl issue. As long as LinuxThreads isn't built, this problem doesn't come up. It seems very likely that it's a glibc problem, then. The Ubuntu builds are NPTL-only and don't show this problem. On the other hand, the LinuxThreads build on other architectures are still fine even with the latest gcc in Debian. -- .''`. 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: [parisc-linux] glibc is broken because of gcc
On the other hand, the LinuxThreads build on other architectures are still fine even with the latest gcc in Debian. Is the __librt_multiple_threads symbol defined, undefined or not used in librt.so? 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]
Re: [parisc-linux] glibc is broken because of gcc
John David Anglin a écrit : Looking at this some more, I don't think there's a missing backport for hppa. There was no reaction on either site. The comment was too vague and will be ignored since you are modifying the gcc tree. If a gcc bug is identified, then a new gcc PR is needed. Well, it was a pr on a backport. I though it was appropriate to add the problem to the long thread. Looking at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428509, I don't see that gcc is doing anything wrong. Currently, I see the following with readelf for __librt_multiple_threads in librt-2.5.so and libc-2.5.so on testing, respectively: 44: 4 OBJECT GLOBAL DEFAULT UND [EMAIL PROTECTED] (10) 1230: 0013e328 4 OBJECT GLOBAL DEFAULT 32 __librt_multiple_threads@@GLIBC_PRIVATE The link error suggests that __librt_multiple_threads is hidden in libc-2.5.so. This will only occur if the symbol is defined with the .hidden attribute. If that's the case, the link error is expected. So, either the symbol shouldn't be hidden or it needs to be defined in librt as well. This is a glibc issue. Here is the readelf of the broken build : [EMAIL PROTECTED]:~/glibc-2.5/build-tree/hppa-libc/rt$ readelf -a ./libc.so |grep multiple_threads 1230: 0013e328 4 OBJECT GLOBAL DEFAULT 32 __librt_multiple_threads@@GLIBC_PRIVATE 2737: 0013e328 4 OBJECT LOCAL HIDDEN 32 __libc_multiple_threads 3961: 0013e328 4 OBJECT GLOBAL DEFAULT 32 __librt_multiple_threads [EMAIL PROTECTED]:~/dev/glibc/glibc-2.5/build-tree/hppa-libc/rt$ readelf -a librt_pic.a |grep multiple_threads 18: 0 NOTYPE GLOBAL HIDDEN UND __librt_multiple_threads 6: 0 NOTYPE GLOBAL DEFAULT UND __librt_multiple_threads 6: 0 NOTYPE GLOBAL DEFAULT UND __librt_multiple_threads I don't see anything wrong. Moreover, the readelf on the correct library gives exactly the same result. To me, the gcc is the bad boy of this story. I wonder if the gcc sees the first hidden symbol and stop there the linking with an error without trying to go further the table to see if another match is possible. In this case, the problem is in the linker. Since I don't really know the details, I'm limited to high level conjectures. I should note that pa gcc backend doesn't do anything special wrt .hidden. .hidden support is handled completely by the middle-end. Thus, any problem wrt .hidden in gcc is likely to apply to all targets that support this attribute. Dave Hum, so this PR is unhiding a bug in the glibc ? Why then other arch don't seem to be impacted ? Seb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc is broken because of gcc
Here is the readelf of the broken build : [EMAIL PROTECTED]:~/glibc-2.5/build-tree/hppa-libc/rt$ readelf -a ./libc.so |grep multiple_threads 1230: 0013e328 4 OBJECT GLOBAL DEFAULT 32 __librt_multiple_threads@@GLIBC_PRIVATE 2737: 0013e328 4 OBJECT LOCAL HIDDEN 32 __libc_multiple_threads 3961: 0013e328 4 OBJECT GLOBAL DEFAULT 32 __librt_multiple_threads [EMAIL PROTECTED]:~/dev/glibc/glibc-2.5/build-tree/hppa-libc/rt$ readelf -a librt_pic.a |grep multiple_threads 18: 0 NOTYPE GLOBAL HIDDEN UND __librt_multiple_threads 6: 0 NOTYPE GLOBAL DEFAULT UND __librt_multiple_threads 6: 0 NOTYPE GLOBAL DEFAULT UND __librt_multiple_threads I don't see anything wrong. Moreover, the readelf on the correct library gives exactly the same result. The error in bug 428509 is: ... /home/seb/dev/glibc-2.5/build-tree/hppa-libc/rt/librt_pic.a(mq_timedreceive.os):(.text+0x20): more undefined references to `__librt_multiple_threads' follow /usr/bin/ld: /home/seb/dev/glibc-2.5/build-tree/hppa-libc/rt/librt.so: hidden symbol `__librt_multiple_threads' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output Looking at gcc PR 20218, it's clear that there are some very subtle issues here. So, it's not clear to me where the problem lies. It could be in glibc (hppa sysdep-cancel.h), binutils or gcc. The handling of the visibility attribute was broken prior to HJL's change, so it could have exposed bugs in other packages. Because of this, it was a mistake for Debian to backport this change. The change is only in the unreleased gcc trunk. Since the problem was introduced by a gcc change, I'd start with a gcc PR and mention the patch that introduced the regression. Could you do glibc builds with the gcc trunk before and after the change? It's best to base the PR on an unmodified version of gcc. It would help to know the exact details of the linker command that fails, the assembler code generated for mq_timedreceive, and the __librt_multiple_threads symbols in __librt_multiple_threads librt.so. 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]
Re: [parisc-linux] glibc is broken because of gcc
The proposed fix seems to be wrong, as it disables the backport on all architectures. Please could you recheck with current trunk? As jda suggested, another backport is missing for hppa. Matthias Sébastien Bernard writes: Ok, I nailed it. I removed PR20218 patch and generated a 4.1.2-12+b1 then build glibc. Glibc build is ok now. I think the hppa toolchain can move on and build the glibc-2.5-11 and then rebuild the portmap and all pie executable (pfeww... what a bug chain). Seb diff -r -u -b -B -w gcc-4.1-4.1.2-12/debian/changelog gcc-4.1-4.1.2-12+b1/debian/changelog --- gcc-4.1-4.1.2-12/debian/changelog 2007-06-13 22:34:38.0 +0200 +++ gcc-4.1-4.1.2-12+b1/debian/changelog 2007-06-13 12:44:48.0 +0200 @@ -1,3 +1,9 @@ +gcc-4.1 (4.1.2-12+b1) unstable; urgency=low + + * Revert 20218 patch that breaks gcc + + -- Sebastien Bernard [EMAIL PROTECTED] Wed, 13 Jun 2007 12:44:07 +0200 + gcc-4.1 (4.1.2-12) unstable; urgency=high * i386-biarch.dpatch: Update for the backport for PR target/31868. diff -r -u -b -B -w gcc-4.1-4.1.2-12/debian/rules.patch gcc-4.1-4.1.2-12+b1/debian/rules.patch --- gcc-4.1-4.1.2-12/debian/rules.patch 2007-06-13 22:34:38.0 +0200 +++ gcc-4.1-4.1.2-12+b1/debian/rules.patch2007-06-13 12:45:06.0 +0200 @@ -41,8 +41,6 @@ fastjar-version \ fastjar-doc \ libstdc++-doxygen \ - pr20218 \ - pr20218-mips \ pr31868 \ arm-libffi \ libffi-backport \ @@ -112,10 +110,6 @@ debian_patches += pr25524-doc pr26885-doc gcc-4.1-x86-blended-doc libjava-backport-updates2 endif -ifneq (,$(filter $(DEB_TARGET_ARCH), amd64 i386 powerpc ppc64 sparc s390)) - debian_patches += pr20218 -endif - ifeq ($(with_libffi),yes) debian_patches += \ libffi-configure ___ parisc-linux mailing list [EMAIL PROTECTED] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] glibc is broken because of gcc
On Tue, Jun 12, 2007 at 06:24:06PM -0400, John David Anglin wrote: Here is the reduced diff. I removed anything that is unrelated to hppa, C or anything. The diff is between -7 and -12. The diff is mere 300 lines long. The problem lies here. The odds are the problem lies in the change to varasm.c. This patch is a part of PR20218. 4.1/4.2 PATCH: PR middle-end/20218: Can't use __attribute__ ((visibility (hidden))) to hide a symbol I could remove this patch altogether. But I still wonder why this patch works ok on other archs and not on hppa*. Seb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc is broken because of gcc
I could remove this patch altogether. But I still wonder why this patch works ok on other archs and not on hppa*. hppa* does a deferred generation of plabels for indirect function calls. I think this is affected by the change. I don't recall exactly but there may have been a followup patch to fix this. Of course, this change isn't in the 4.1 GCC tree. 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]
Re: [parisc-linux] glibc is broken because of gcc
On Wed, Jun 13, 2007 at 09:32:24AM -0400, John David Anglin wrote: I could remove this patch altogether. But I still wonder why this patch works ok on other archs and not on hppa*. hppa* does a deferred generation of plabels for indirect function calls. I think this is affected by the change. I don't recall exactly but there may have been a followup patch to fix this. Of course, this change isn't in the 4.1 GCC tree. Ok, thanks for the explanations. I just have to figure out what it means now ;-). Can I find this patch somewhere ? Is there any discussion on the ML ? The patch was discussed near January of this year on the gcc ML. 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]
Re: [parisc-linux] glibc is broken because of gcc
[EMAIL PROTECTED] a écrit : On Wed, Jun 13, 2007 at 09:32:24AM -0400, John David Anglin wrote: I could remove this patch altogether. But I still wonder why this patch works ok on other archs and not on hppa*. hppa* does a deferred generation of plabels for indirect function calls. I think this is affected by the change. I don't recall exactly but there may have been a followup patch to fix this. Of course, this change isn't in the 4.1 GCC tree. Ok, thanks for the explanations. I just have to figure out what it means now ;-). Can I find this patch somewhere ? Is there any discussion on the ML ? The patch was discussed near January of this year on the gcc ML. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) Ok, I nailed it. I removed PR20218 patch and generated a 4.1.2-12+b1 then build glibc. Glibc build is ok now. I think the hppa toolchain can move on and build the glibc-2.5-11 and then rebuild the portmap and all pie executable (pfeww... what a bug chain). Seb diff -r -u -b -B -w gcc-4.1-4.1.2-12/debian/changelog gcc-4.1-4.1.2-12+b1/debian/changelog --- gcc-4.1-4.1.2-12/debian/changelog 2007-06-13 22:34:38.0 +0200 +++ gcc-4.1-4.1.2-12+b1/debian/changelog2007-06-13 12:44:48.0 +0200 @@ -1,3 +1,9 @@ +gcc-4.1 (4.1.2-12+b1) unstable; urgency=low + + * Revert 20218 patch that breaks gcc + + -- Sebastien Bernard [EMAIL PROTECTED] Wed, 13 Jun 2007 12:44:07 +0200 + gcc-4.1 (4.1.2-12) unstable; urgency=high * i386-biarch.dpatch: Update for the backport for PR target/31868. diff -r -u -b -B -w gcc-4.1-4.1.2-12/debian/rules.patch gcc-4.1-4.1.2-12+b1/debian/rules.patch --- gcc-4.1-4.1.2-12/debian/rules.patch 2007-06-13 22:34:38.0 +0200 +++ gcc-4.1-4.1.2-12+b1/debian/rules.patch 2007-06-13 12:45:06.0 +0200 @@ -41,8 +41,6 @@ fastjar-version \ fastjar-doc \ libstdc++-doxygen \ - pr20218 \ - pr20218-mips \ pr31868 \ arm-libffi \ libffi-backport \ @@ -112,10 +110,6 @@ debian_patches += pr25524-doc pr26885-doc gcc-4.1-x86-blended-doc libjava-backport-updates2 endif -ifneq (,$(filter $(DEB_TARGET_ARCH), amd64 i386 powerpc ppc64 sparc s390)) - debian_patches += pr20218 -endif - ifeq ($(with_libffi),yes) debian_patches += \ libffi-configure
Re: [parisc-linux] glibc is broken because of gcc
On Mon, Jun 11, 2007 at 06:27:45PM +0200, [EMAIL PROTECTED] wrote: Here is the diff from environnement : Package | buildd vers | current vers --- make | 3.81.3| 3.81.3 gawk | 3.1.5.dfsg-4 | 3.1.5.dfsg-4 intltool-debian | 0.35.0+20060710.1 | 0.35.0+20060710.1 gettext-base | 0.16.1-1 | 0.16.1-1 gettext | 0.16.1-1 | 0.16.1-1 autoconf | 2.61-4| 2.61-4 html2text | 1.3.2a-3+b1 | 1.3.2a-3+b1 po-debconf| 1.0.8 | 1.0.8 bzip2 | 1.0.3-7 | 1.0.3-7 lzma | 4.43-7| 4.43-7 diffstat | 1.43-2| 1.43-2 m4| 1.4.9-1 | 1.4.9-1 quilt | 0.46-2| 0.46-2 -- dpkg-dev | 1.14.3| 1.14.4 sed | 4.1.5-1 | 4.1.5-2 binutils | 2.17cvs20070428-6 | 2.17cvs20070426-8 gcc-4.1 | 4.1.2-7 | 4.1.2-11 g++-4.1 | 4.1.2-7 | 4.1.2-12 libstdc++6-4.1-dev | 4.1.2-7 | 4.1.2-12 libstdc++6| 4.1.2-7 | 4.1.2-12 libmagic1 | 4.20-8| 4.21-1 file | 4.20-8| 4.21-1 debhelper | 5.0.49 | 5.0.50 linux-libc-dev| 3.6.21-2 | 2.6.21-4 libc6-dev | 2.5-7 | 2.5-9 -- We have a winner. The glibc build breakage is the gcc fault. The gcc-4.1 4.1.2-8 builds the package ok. The gcc-4.1 4.1.2-11 is ko. Seb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc is broken because of gcc
On Tue, Jun 12, 2007 at 10:48:06AM +0200, [EMAIL PROTECTED] wrote: The gcc-4.1 4.1.2-8 builds the package ok. The gcc-4.1 4.1.2-11 is ko. Seb Problem logged on debian bug #428509. Seb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc is broken because of gcc
[EMAIL PROTECTED] a écrit :
On Tue, Jun 12, 2007 at 10:48:06AM +0200, [EMAIL PROTECTED] wrote:
The gcc-4.1 4.1.2-8 builds the package ok.
The gcc-4.1 4.1.2-11 is ko.
Seb
Problem logged on debian bug #428509.
Seb
___
parisc-linux mailing list
[EMAIL PROTECTED]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Here is the reduced diff. I removed anything that is unrelated to hppa,
C or anything.
The diff is between -7 and -12.
The diff is mere 300 lines long.
The problem lies here.
diff -r -u -b -B -w gcc-4.1-4.1.2-7/src/configure gcc-4.1-4.1.2-12/src/configure
--- gcc-4.1-4.1.2-7/src/configure 2007-06-12 22:08:36.0 +0200
+++ gcc-4.1-4.1.2-12/src/configure 2006-11-21 18:48:36.0 +0100
@@ -16,8 +16,6 @@
ac_help=$ac_help
--enable-libsspBuilds libssp directory
ac_help=$ac_help
- --enable-libffiBuilds libffi directory
-ac_help=$ac_help
--with-mpfr-dir=PATHSpecify source directory for MPFR library
ac_help=$ac_help
--with-mpfr=PATHSpecify directory for installed MPFR library
@@ -1109,20 +1107,6 @@
noconfigdirs=$noconfigdirs target-libssp
fi
-# Check whether --enable-libffi or --disable-libffi was given.
-if test ${enable_libffi+set} = set; then
- enableval=$enable_libffi
- ENABLE_LIBFFI=$enableval
-else
- ENABLE_LIBFFI=yes
-fi
-
-if test ${ENABLE_LIBFFI} != yes ; then
- noconfigdirs=$noconfigdirs target-libffi
-else
- libgcj=`echo $libgcj | sed 's/target-libffi *//'`
-fi
-
# Save it here so that, even in case of --enable-libgcj, if the Java
# front-end isn't enabled, we still get libgcj disabled.
libgcj_saved=$libgcj
diff -r -u -b -B -w gcc-4.1-4.1.2-7/src/configure.in
gcc-4.1-4.1.2-12/src/configure.in
--- gcc-4.1-4.1.2-7/src/configure.in2007-06-12 22:08:36.0 +0200
+++ gcc-4.1-4.1.2-12/src/configure.in 2006-11-21 18:48:36.0 +0100
@@ -315,16 +315,6 @@
noconfigdirs=$noconfigdirs target-libssp
fi
-AC_ARG_ENABLE(libffi,
-[ --enable-libffiBuilds libffi directory],
-ENABLE_LIBFFI=$enableval,
-ENABLE_LIBFFI=yes)
-if test ${ENABLE_LIBFFI} != yes ; then
- noconfigdirs=$noconfigdirs target-libffi
-else
- libgcj=`echo $libgcj | sed 's/target-libffi *//'`
-fi
-
# Save it here so that, even in case of --enable-libgcj, if the Java
# front-end isn't enabled, we still get libgcj disabled.
libgcj_saved=$libgcj
diff -r -u -b -B -w gcc-4.1-4.1.2-7/src/gcc/cgraphunit.c
gcc-4.1-4.1.2-12/src/gcc/cgraphunit.c
--- gcc-4.1-4.1.2-7/src/gcc/cgraphunit.c2007-01-05 20:44:10.0
+0100
+++ gcc-4.1-4.1.2-12/src/gcc/cgraphunit.c 2007-06-12 22:13:19.0
+0200
@@ -1330,8 +1330,6 @@
return;
}
- process_pending_assemble_externals ();
-
/* Frontend may output common variables after the unit has been finalized.
It is safe to deal with them here as they are always zero initialized. */
cgraph_varpool_analyze_pending_decls ();
diff -r -u -b -B -w gcc-4.1-4.1.2-7/src/gcc/combine.c
gcc-4.1-4.1.2-12/src/gcc/combine.c
--- gcc-4.1-4.1.2-7/src/gcc/combine.c 2007-01-21 23:34:57.0 +0100
+++ gcc-4.1-4.1.2-12/src/gcc/combine.c 2007-06-12 22:12:56.0 +0200
@@ -5443,11 +5443,11 @@
SUBST(SET_SRC (x), op0);
src = SET_SRC (x);
}
- else
- {
/* Otherwise, update the COMPARE if needed. */
- SUBST (XEXP (src, 0), op0);
- SUBST (XEXP (src, 1), op1);
+ else if (XEXP (src, 0) != op0 || XEXP (src, 1) != op1)
+ {
+ SUBST (SET_SRC (x), gen_rtx_COMPARE (compare_mode, op0, op1));
+ src = SET_SRC (x);
}
}
else
--- gcc-4.1-4.1.2-7/src/gcc/config/elfos.h 2006-08-01 00:08:47.0
+0200
+++ gcc-4.1-4.1.2-12/src/gcc/config/elfos.h 2007-06-12 22:13:19.0
+0200
@@ -494,3 +494,13 @@
fprintf ((FILE), \\n); \
} \
while (0)
+
+/* A C statement (sans semicolon) to output to the stdio stream STREAM
+ any text necessary for declaring the name of an external symbol
+ named NAME whch is referenced in this compilation but not defined.
+ It is needed to properly support non-default visibility. */
+
+#ifndef ASM_OUTPUT_EXTERNAL
+#define ASM_OUTPUT_EXTERNAL(FILE, DECL, NAME) \
+ default_elf_asm_output_external (FILE, DECL, NAME)
+#endif
diff -r -u -b -B -w gcc-4.1-4.1.2-7/src/gcc/config/t-libc-ok
gcc-4.1-4.1.2-12/src/gcc/config/t-libc-ok
--- gcc-4.1-4.1.2-7/src/gcc/config/t-libc-ok2002-11-26 23:47:18.0
+0100
+++ gcc-4.1-4.1.2-12/src/gcc/config/t-libc-ok 2007-06-12 22:13:19.0
+0200
@@ -1 +1 @@
-CRTSTUFF_T_CFLAGS_S=-fPIC
+CRTSTUFF_T_CFLAGS_S = $(CRTSTUFF_T_CFLAGS) -fPIC
diff -r -u -b -B -w gcc-4.1-4.1.2-7/src/gcc/config/t-netbsd
gcc-4.1-4.1.2-12/src/gcc/config/t-netbsd
--- gcc-4.1-4.1.2-7/src/gcc/config/t-netbsd 2003-09-23 20:56:00.0
Re: [parisc-linux] glibc is broken because of gcc
Here is the reduced diff. I removed anything that is unrelated to hppa, C or anything. The diff is between -7 and -12. The diff is mere 300 lines long. The problem lies here. The odds are the problem lies in the change to varasm.c. 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]
