Looks like WINE, the Windows non-emulator for Linux, is going to have some problems making the shift to glibc2.3. WINE has its own implementation of threads, which glibc doesn’t know about. Part of the act of splicing this implementation into the old glibc involved gently pursuading the library to look in a different location for system error result codes. That hack doesn’t work in the new glibc.
It looks like the solution may be to port WINE to libc threads, which is a bit terrifying. Previously, it’s been out of the question, because there just wasn’t a good match between pthreads system and the Windows model. A combination (I think) of the new kernel’s thread implementation and improvements in pthreads itself may fix that, but it’s still a big leap.
If WINE does make the move, a few other bonuses fall out of the work. Firstly, Mono, the Unix port of .NET, would be able to re-use WINE code for its graphics and UI libraries. And because WINE would no longer be bbolting strangeness onto glibc, the project would be able to use Valgrind, the open-source memory debugger for x86-Linux.
There are political ramifications also. The WINE project is in a curious configuration at the moment, with several groups keeping their own mildly forked versions (either for business reasons, or because of disagreements over licensing). They’re all going to have to come together to co-operate with this – and in pretty smart order, because Redhat ships with the new glibc in a few months.
These are the kind of shifts that often utterly devastate private programming projects. They can be pretty stressful for open source endeavours too. If you are at all curious how free software copes with major logistical challenges, this would be a good project to watch.