[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Etch ....

Regarding my comments about the not-cancel.h file, the separate architecture versions are in the NPTL area, so probably not an option.


Tom Evans wrote:

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 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

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 it
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.


Reply to: