This is the mail archive of the libc-alpha@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]

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]),




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