I was rather surprised to see glibc 2.4 come straight into ~arch, I would have expected it to have gone into package mask for a while first. I have not yet started to upgrade, I am still running gcc 3.4.5 but the gnu announcement for glibc 2.4 states that gcc 4.1 is prefered but this is package masked and I am not sure I want to try upgrading 2 major components at once.

The developer cleary stated from the beginning that linuxthreads was a hack and nobody should rely on it being a permanent solution. Hey, fortunately NPTL was designed backwards-compatible and programes compiled against linuxthreads work with it out-of-the-box. And usually it does. Except for programs which did fiddle with linuxthread internals or relied on linuxthreads behaviour whereas the documentation stated that they shouldn't have done that.

Linuxthreads should die. So should developers who wrote software that doesn't work without it.

This is once more proof that closed-source software sucks and hinders software evolution.

Are you sure? How come? This is a maintained (or at least open-source, so someone could fix it) program and if I see correctly it uses perl so it shouldn't fiddle around with threading itself. I can't really believe that it might have problems with NPTL.

: I personally have completely dropped linuxthreads two years ago and never looked back.

Seems the new glibc breaks the header file for ruby, so when you try to build koffice which has ruby dependency, it will fail on ruby includes, just re-merge ruby with the new glibc can solve this problem.

And another problem is it seems it breaks some jpeg related application, for example, gimp, gimp can open some jpeg files, but cann't open jpeg files shoted by Minolta Alpha 5D, just re-merge jpeg and gimp, solved this problem.

In overlay I have flag gcc4ssp to enable ssp support with gcc 4. In portage it is enabled by default? There is no such flag in portage. Adding NPTL_KERNEL_VERSION="2.6.11" to make.conf helped to fix problem about kernel headers. What about SSP?