I imagine that no one followed up on the bug because the it was marked as closed with the RESPONSE
that 2.5-exp3 *is* the fix for #325600.That gave many of us the expectation that a 2.5 series glibc would make its way into testing and then to stable with the Etch release, I mean why else would the maintainers mark such a critical bug as being fixed
in that way?It really wasn't an issue so long as the glibc in stable was okay - no one was expecting Etch to be released with that flawed glibc because it was MARKED as closed (granted with a 2.5 series that made little sense).
I do not understand the first sentence above, but I'm so sorry that I offered a possible list of explanations. Perhaps it would have been better to have posted fewer details about the experience of tracking itI for one don't understand why the patch offered in #325600 and haven't had a chance to examine the consequences of the proposed change. Further, your comments in the bug that the real bug might be an optimizer bug, or a broken inline_syscall4 implementation, don't inspire me to urge the glibc maintainers to apply such a patch without digging a lot deeper into it myself.
down to the single line of code where the problem was located.Sometimes in complicated software, one cannot always easily find and understand the root cause failure. I took it as far as I could in the time I had - I thought that passing it to the "experts" was the correct thing to do.
I noticed that in newer glibc sources that the not-cancel.h header file is now separated via architecture. There is one for i386, sparc, x86_64, etc (they all point to the i386 version at the moment), but that implies that an alpha specific version is possible and with that, a change that ONLY affects alpha should be possible.
...tom
If someone can address these doubts with some measure of authority, I'd be happy to ask the glibc maintainers and stable release managers to include a fix in etch r1, but from the bug log it looks like no one has bothered following up on the bug since a fix became available in experimental -- which is totally the wrong fix for etch, because experimental's glibc is NPTL-only, making it a separate codebase for thread handling. (And the current build failures on alpha are in NPTL now besides, so...)