This is the mail archive of the glibc-bugs@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


------- Additional Comments From nix at esperi dot org dot uk  2005-01-31 23:12 -------
A semi-confirmation here: I see identical symptoms. Notably, I see it on an
i586-pc-linux-gnu no matter what --enable-kernel option I try (I've tried 2.4.1
and 2.4.28 so far); I haven't seen it on i686-pc-linux-gnu at all.

I think you'll see it whenever you don't explicitly specify the --build or
--host to be an i686 at configure time.

The cause is that pthread.c states, in part

#if !(USE_TLS && HAVE___THREAD)
/* These variables are used by the setup code.  */
extern int _errno;
extern int _h_errno;
[...]

and on machines lower than i686, USE_TLS is not defined; it is protected by

/* We can support TLS only if the floating-stack support is available.
   However, we want to compile in the support and test at runtime whether
   the running kernel can support it or not.  To avoid bothering with the
   TLS support code at all, use configure --without-tls.

   We need USE_TLS to be consistently defined, for ldsodefs.h conditionals.
   But some of the code below can cause problems in building libpthread
   (e.g. useldt.h will defined FLOATING_STACKS when it shouldn't).  */

#if defined HAVE_TLS_SUPPORT \
    && (defined FLOATING_STACKS || !defined IS_IN_libpthread)

/* Signal that TLS support is available.  */
# define USE_TLS        1
[...]

and on machines less than i686, FLOATING_STACKS support is not available
(because useldt.h is only included by i686's pt-machine.h, not i386's.)

You can `fix' this by configuring --without-tls when building a non-NPTL libc,
but that'll lead to NPTL's rtld.c incorporating TLS support, and non-NPTL's not.
I think that'd probably cause substantial problems.

Alternatively, you can do what all the distributors have done, and re-export
_errno and _h_errno, at least within the GLIBC_PRIVATE domain. I'm trying to
make that work now, but private symbol exporting is somewhat black magic to me,
and I haven't managed to do it yet.

-- 


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]