This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Must choose one of nptl, linuxthreads
- From: Enrique Perez-Terron <enrio at online dot no>
- To: libc-alpha at sources dot redhat dot com
- Date: Thu, 26 Aug 2004 19:28:49 +0200
- Subject: Must choose one of nptl, linuxthreads
It seems that --enable-add-ons can no longer be used without arguments,
or what is the matter?
I did cvs update today. KERNELDIR is linux-2.6.8-1.531 (current fedora core 2),
while the running kernel is 2.6.6-* (fedora core 2 a week ago or so)
mkdir $BUILDROOT
cd $BUILDROOT
$GLIBCDIR/libc/configure \
--prefix=/usr \
--with-tls \
--enable-add-ons \
--enable-kernel=$KERNELVERSION \
--with-headers=$KERNELDIR/include \
--disable-profile \
|| exit 1
checking for kernel header at least 2.6.6... ok
*** LinuxThreads and NPTL add-ons are both available. Only one must be used.
+ exit 1
IIRC -with-tls used to induce configure to choose nptl, or perhaps I
misunderstood?
If I say -with-add-ons=nptl I get no other add-ons, right?
The fedora glibc source rpm contains a large number of add-ons, while
the cvs appears to have only three. But then I have to dig into the
configure script to find out how one determines what constitutes an
add-on. (cd $srcdir; ls */configure 2>/dev/null) This is hardly user
friendly.
I admit to know rather little about the subject, does the patch below do
the right thing? If the user has specified --with-add-ons with no
argument (or with "yes"), then the choice depends on the decision to use
TLS or not. If TLS is used, pick ntpl. The test for with[out]-tls is
moved ahead of add-ons to make its result available to the add-ons code.
Perhaps the choice should also depend on kernel-version, picking
linuxthreads unless the version is 2.6 or higher. (Redhat backported
ntpl to 2.4.20 but then let users use a redhat configuration script.)
Perhaps the choice should also depend on the target architecture; i386
does not support nptl IIRC, etc. Are there no tests in nptl/configure to
determine if nptl actually makes sense?
I observe nptl/configure is empty. Perhaps sysdeps/* contains something?
-Enrique
--- configure.in.orig 2004-08-12 08:12:22.000000000 +0200
+++ configure.in 2004-08-26 18:31:22.000000000 +0200
@@ -169,25 +169,34 @@
fi
AC_SUBST(oldest_abi)
+dnl Let the user avoid using TLS. Don't know why but...
+dnl XXX For now we disable support by default.
+AC_ARG_WITH([tls],
+ AC_HELP_STRING([--with-tls],
+ [enable support for TLS]),
+ [usetls=$withval],
+ [usetls=no])
+
dnl Generic infrastructure for drop-in additions to libc.
AC_ARG_ENABLE([add-ons],
AC_HELP_STRING([--enable-add-ons@<:@=DIRS...@:>@],
[configure and build add-ons in DIR1,DIR2,... search for add-ons if no parameter given]),
[case "$enableval" in
yes) add_ons=`cd $srcdir && echo */configure | sed -e 's!/configure!!g'`
- test "$add_ons" = "*" && add_ons= ;;
+ test "$add_ons" = "*" && add_ons=
+ case "$add_ons" in
+ *nptl*linuxthreads* | *linuxthreads*nptl* )
+ case "$usetls" in
+ yes) add_ons=$(echo "$add_ons" | tr ' ' '\012' | grep -v '^linuxthreads$');;
+ *) add_ons=$(echo "$add_ons" | tr ' ' '\012' | grep -v '^nptl$');;
+ esac
+ add_ons=$(echo $add_ons)
+ ;;
+ esac;;
*) add_ons=`echo "$enableval" | sed 's/,/ /g'`;;
esac],
[add_ons=])
-dnl Let the user avoid using TLS. Don't know why but...
-dnl XXX For now we disable support by default.
-AC_ARG_WITH([tls],
- AC_HELP_STRING([--with-tls],
- [enable support for TLS]),
- [usetls=$withval],
- [usetls=no])
-
AC_ARG_WITH([__thread],
AC_HELP_STRING([--without-__thread],
[do not use TLS features even when supporting them]),