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]
[D-I] Kernel/module udebs status - massbuild script update
(Reply-to set to debian-boot list) kernel udeb status == Because I had to test the changes below anyway, I have done what I guess will be my last massbuild and upload of kernel/module udebs. All arches are now at 2.6.21-2, with the following exceptions: - sparc: at 2.6.20 because sparc32 is not enabled in 2.6.21; I've been waiting for a formal decision about whether sparc32 is going to be dropped for lenny or not [1]; Jurij Smakov is going to follow up on that soon - hppa: at 2.6.18 because the parisc64 kernels are seriously broken [2]; however, it may be better to update the kernel despite this - powerpc: at 2.6.18; until now we've never had all needed source packages available; I've asked Colin to do the update and hope he'll find time soon We'll switch the updated arches to 2.6.21-2 once they are through NEW. All up-to-date arches now have both loop-eas and squashfs module udebs, except: - arm: only loop-aes as squashfs is not available - m68k: has neither because loop-aes was never available and given current status of the arch it does not really make sense to upload for only squashfs massbuild script With the addition by Otavio of squashfs udebs to the linux-module-di packages (for the live CD project), a new version of the massbuild script was needed to support the fact that there are now two dependencies (binaries from loop-aes and linux-modules-extra-2.6). Today I have made the necessary changes and in the process merged the two previous scripts and the new script more generic. There were of course some challenges (especially the version numbering for squashfs). Some highlights: - desired version of dependencies is no longer passed as a parameter, but read from a file 'massbuild.versions' - the --incoming option will now make the build try incoming _after_ trying the regular mirror - a separate line is added in the changelog for each build dependency and specifies the version the package was built against - the '-m changelog text' option will now _add_ an extra line in the changelog instead of overruling the default entries; if multiple lines are passed, they will be added as separate entries As all these changes IMO make the script mature enough, I have moved it to the packages/kernel directory in trunk. Cheers, FJP [1] So far this has only been discussed, but the project has not yet made a formal decision: - http://lists.debian.org/debian-devel-announce/2007/05/msg7.html - http://lists.debian.org/debian-devel/2007/05/msg00804.html [2] http://bugs.debian.org/426391 pgpv94CRhOTcT.pgp Description: PGP signature
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]
