Tim Jackson wrote:
Can anyone offer any advice? Is this a bug in the libstdc++ package? Is there a likely workaround? I'm afraid I don't know enough about NPTL/libstdc++ to really understand the details of what's going on here.
I don't know much about NPTL/libstdc++. However, what I do know is that Red Hat made decision to require NPTL very long time ago. If your system can't run NPTL enabled kernel and glibc (or whatever other library), it is unsupported and it isn't likely anybody will work on it to fix it. Even if you were paying Red Hat customer. Things might work, and than they might mysteriously break one day.
I've mentioned one example in the other thread couple of days ago. In FC2, glibc didn't have NPTL support on i586 (it used i386 version of glibc, and i386 doesn't have instructions needed to implement NPTL). The fix was to create "unclean" i386 package using i486 instructions to get NPTL support into i386 glibc. However, note that the architecture (i586) was able to run NPTL-enabled glibc. If your system can't run NPTL-enabled glibc at all (I don't know much about UML), than the problem most likely can't be fixed. The fact that it used to work with the older versions is of little relevance here. You were simply lucky, and your luck just ran out.
For example, if you don't have working NPTL it is very likely that some of the RHEL4/CentOS4 packages wouldn't work even with the older version of the libraries (cyrus-imapd is the one that would probably break, the way it was broken in i586 FC2, its DB4 based database backend heavily depends on NPTL).