Description of Problem:
If user program is linked with glibc statically, locale support will not be
initialised properly in threads. As a result, application doesn't work properly.
Version-Release number of selected component (if applicable):
This patch fixes the problem:
--- glibc-2.3/linuxthreads/manager.c.orig Wed Aug 28 10:07:50 2002
+++ glibc-2.3/linuxthreads/manager.c Tue Oct 22 11:29:37 2002
@@ -283,7 +283,7 @@
-#if !(USE_TLS && HAVE___THREAD) && defined SHARED
+#if !(USE_TLS && HAVE___THREAD)
/* Initialize thread-locale current locale to point to the global one.
With __thread support, the variable's initializer takes care of this. */
BTW, this is the only place in manager.c when "&& define SHARED" is used with
!(USE_TLS && HAVE___THREAD). Is it really needed here?
This bug is currently biting me very badly. I have a deployed system running red
hat 7.1. I have upgraded my compile system to red hat 8.0. I now cannot compile
my application for my deployed system - compiling without "-static" gives me
binaries that won't run because the 7.1 system is missing the needed .so files,
compiling with "-static" gives me a binary that crashes whenever I call a
function that uses locale! Ouch!
Time to try moving the RH7.1 glibc.so files onto the 8.0 system, so I can link
dynamically...I'll keep my fingers crossed. But it would be great to get a fix
so "-static" works again.
It is fixed in rawhide glibc for quite some time.
It will surely make into errata when it is released.