The attached code (assuming I manage to attach it) shows that there is a problem
with thread-local storage when used from a library and a static class member. 
The attached code creates 10 threads.  Each thread uses 3 different mechanisms
to store the thread's identity in thread-local storage: (1) in a global
thread-local variable, (2) in a static member of a class, (3) in a static member
of an instantiated template class.  Each thread prints out its values for each
of these after thread start and before thread end.  You should see each thread
reporting the same value for each storage mechanism (and different values for
the thread-local storage addresses).  This is what happens on our Solaris and
Windows platforms.   
 
However, this does not happen on RedHat, because for mechanisms (2) and (3),
each mechanism shares the data across the threads (the threads do not have their
own location).  As a result, typically the "thread…ends" output for each thread
contains the correct value and unique address for mechanism (1), but for (2) and
(3) the values and addresses are of one (or two) of the threads.
 
It appears (see GCC bugzilla #13668) that this bug is due to glibc.  I've seen
this problem on RHEL3 and RHEL4.  My RHEL4 is using 3.4.4 20050721 (Red Hat
3.4.4-2), though I've tried it with a locally built 4.0.2 also.  Sorry, I don't
know how to tell the version of libc, it's out-of-the-box.

To see the problem, unpack the attached tgz and "make && ./a.out".  You will see
the first (and second) column correctly showing unique thread ids (and addresses
where the values are stored), but the other columns will not.