[Bug linuxthreads/674] Error compiling linuxthreads in glibc 2.3.4

["nix at esperi dot org dot uk" <sourceware-bugzilla@sources.redhat.com>]

------- Additional Comments From nix at esperi dot org dot uk  2005-02-01 11:20 -------
(In reply to comment #1)

(tls.h)
> #if defined HAVE_TLS_SUPPORT \
>     && (defined FLOATING_STACKS || !defined IS_IN_libpthread)
> 
> /* Signal that TLS support is available.  */
> # define USE_TLS        1
> [...]

The problem is that _errno, _res, _h_errno and the other symbols causing such
conniptions are declared in errno.c and herrno.c using a construct like this:

#if USE___THREAD
 [defines e.g. herrno as alias for thread variable __libc_h_errno]
#else
 [defines e.g. herrno and _h_errno, and compatibility symbols for them
  in GLIBC_2_0]
#endif

The problem is that because of that `!defined IS_IN_libpthread' in the tls.h
included when the linuxthreads add-on is built, we end up with different values
of USE_TLS, and thus of USE___THREAD, in the libc and in linuxthreads on a
machine without floating stacks. (Specifically, it is true in libc and false in
linuxthreads). Thus linuxthreads looks for exported variables which aren't just
not exported from libc, but don't exist there.

libc's decision is obviously correct: if __thread is available, you *should* use
it for errno; this won't change merely because floating stacks happen to be
available in one particular threading implementation. So something needs to
change in linuxthreads.

I'm still not sure what. That code is a bit of a maze, with HAVE___THREAD and
USE_TLS interacting in ways that are still unclear to me.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=674

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.