> Now I am very happy with alpha support, the only thing is the problem
> with multithreaded apps (the bug in glibc that creates defunct
> processes)! Is there any news about that? This is very annoying
> because there is a patch available for that since about 3-4 months!!!
> Why is nobody able to apply this patch to glibc without discussing
> all the time about pros and cons that does not matter?
Sorry, to you have a pointer to the patch for this? I don't think there are
any alpha porters actively involved in the glibc packaging right now; I
guess there ought to be, but so far alpha has generally been reliable enough
that there hasn't been a need. :/ Of course, I'm sure even with commit
access I can't apply it without figuring out what pros and cons *do* matter,
so you might want to spell out which ones you believe don't matter :)
From: Tom Evans <tom@23palmer.net> To: Tom Evans <tom@23palmer.net> Cc: 325600@bugs.debian.org, debian-alpha@lists.debian.org Subject: Re: 325600 (<defunct> threads on Alpha). Date: Tue, 25 Oct 2005 14:59:24 -0400
If I simply change (in linuxthreads/sysdep/unix/sysv/linux/not-cancel.h) from: # define waitpid_not_cancel(pid, stat_loc, options) \ INLINE_SYSCALL (osf_wait4, 4, pid, stat_loc, options, NULL) to: # define waitpid_not_cancel(pid, stat_loc, options) \ wait4( pid, stat_loc, options, NULL ) all is well - I understand the performance benefits of the inlining, but since x86 is NPTL anyway, perhaps this is an okay solution? I'm guessing that there is an Alpha-related optimizer bug perhaps? Or that the inline_syscall4 in sysdep/unix/alpha/sysdep.h is somehow broken?
> Or the other chance to fix that: What about NPTL - are the buildd's
> now linux2.6 and can compile NPTL libc's?
I think we have 2.6 on the buildds now, but I don't know what the plans are
for NPTL. We can't reasonably make a complete switch to NPTL-only until we
know what the upgrade path from sarge will look like, or until after etch's
release; there are already problems with circular deps between the kernels
and the initramfs tools, so we need to plan carefully any changes to this
area.