numerous observations/questions about contrib NPTL patch

[Robert P. J. Day]

  just about to head out for a couple of hours, so i might as well
dump all this out there and see if there are replies when i get back.

  re: the contrib patch file

	contrib/2005b/crosstool-0.38-nptl-schaefer.patch

and the part that pertains to patching the glibc headers step.  first,
there's this:

======================
+if test '!' -z "${GLIBC_ADDON_NPTL}"; then
+    GLIBC_EXTRA_CONFIG="--with-tls --with-__thread ${GLIBC_EXTRA_CONFIG}"
+    GLIBC_MIN_KERNEL=2.6.4
+else
+    GLIBC_EXTRA_CONFIG="--without-tls --without-__thread ${GLIBC_EXTRA_CONFIG}"
+    GLIBC_MIN_KERNEL=2.4.3
+fi
======================

  fair enough:  add the thread-related configure options (but *note*
that there is no addition of the option "--enable-add-ons=nptl".
apparently, you don't need that *here*, only later.)

  but here comes the more salient part of that patch file:

=======================

+    if test '!' -z "${GLIBC_ADDON_NPTL}"; then
+        # To build gcc with thread support requires real pthread headers. These
+        # will have to manually be copied from under the tree of the desired
+        # target pthread implementation.
+        cp ${GLIBC_DIR}/nptl/sysdeps/pthread/pthread.h $HEADERDIR/pthread.h
+        pthreadtypes_h=nptl/sysdeps/unix/sysv/linux/${ARCH}/bits/pthreadtypes.h
+
+        # On s390, powerpc and sparc we also require bits/wordsize.h.
+        case $TARGET in
+        sparc* | s390* | powerpc* )
+            case $TARGET in
+            sparc64* )   wordsize_h=sysdeps/sparc/sparc64/bits/wordsize.h
+                        pthreadtypes_h=nptl/sysdeps/unix/sysv/linux/sparc/bits/pthreadtypes.h
+                        ;;
+            sparc* )    wordsize_h=sysdeps/sparc/sparc32/bits/wordsize.h
+                        pthreadtypes_h=nptl/sysdeps/unix/sysv/linux/sparc/bits/pthreadtypes.h
+                        ;;
+            s390x* )    wordsize_h=sysdeps/s390/s390x/bits/wordsize.h
+                        ;;
+            s390* )      wordsize_h=sysdeps/s390/s390/bits/wordsize.h
+                        ;;
+            powerpc64* ) wordsize_h=sysdeps/powerpc/powerpc64/bits/wordsize.h
+                        pthreadtypes_h=nptl/sysdeps/unix/sysv/linux/powerpc/bits/pthreadtypes.h
+                        ;;
+            powerpc* )  wordsize_h=sysdeps/powerpc/powerpc32/bits/wordsize.h
+                        pthreadtypes_h=nptl/sysdeps/unix/sysv/linux/powerpc/bits/pthreadtypes.h
+                        ;;
+            esac
+            test ! -f $HEADERDIR/bits/wordsize.h && cp ${GLIBC_DIR}/${wordsize_h} $HEADERDIR/bits/wordsize.h
+            cp ${GLIBC_DIR}/${pthreadtypes_h} $HEADERDIR/bits/pthreadtypes.h
+           ;;
+       esac
+    fi # GLIBC_ADDONS_NPTL
=======================

  first, it's fairly obvious what the above does -- it guarantees
that, after the regular glibc header install, some missing parts may
have to be installed manually, and these header files are:

	pthread.h
	pthreadtypes.h
	wordsize.h

so far, so good.  now, the *not* so good parts.

1) s390 is broken.  there are no "s390/s390" or "s390/s390x"
directories in glibc-2.3.6/sysdeps (anymore).  now, it's
"s390/s390-32" and "s390/s390-64", so trying to copy the wordsize.h
file for s390 is guaranteed to fail, at least the way i read it.  in
short, the above patch seems to be a bit out of date.

2) are the manual copies of wordsize.h and the thread-related files
somehow connected?  the above suggests that wordsize.h is copied over
manually *only* if you've selected NPTL.  does that make sense?
doesn't wordsize.h sound like a file that should be part of the
standard install in the first place?  just sayin'.

in any case, it would probably be clearer if wordsize.h was processed
separately from the thread-related header files.  that would certainly
make the script easier to read.

3) why is it necessary to *manually* copy over the thread-related
files as well?  can't you configure that step so that those copies are
part of the basic install?  i mean, you've selected "--with-tls" and
"--with-__thread" but, apparently, that's not enough.  what if you
added "--enable-add-ons-nptl" (even though that's not technically
required at this step.)

in short, if you're going to build for NPTL, shouldn't the glibc
headers install step install those header files for you once it
realizes what you're doing?

  anyway, i'm outta here for a bit.  any feedback appreciated.

rday

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.org