Hi!
I'd like to make NPTL the default threading library for FC3,
as a step in phasing out LinuxThreads.
In FC2, when compiling a program which #include <pthread.h>,
or other POSIX THR option headers (or e.g. limits.h) or
when linking against -lpthread, it is compiled against
LinuxThreads headers and linked against LinuxThreads libpthread.so.
To use NPTL headers and/or link against NPTL libpthread.so,
one has to use -I/usr/include/nptl -L/usr/lib{,64}/nptl
Dynamically linked programs are then run by default against
NPTL libraries (unless LD_ASSUME_KERNEL < 2.4.19 is used),
as NPTL libraries are backwards ABI compatible with LinuxThreads
libraries, but not vice versa.
In FC3, I'd like programs to link against NPTL libpthread.so/libpthread.a
and compile against NPTL headers by default and provide some
-I/usr/include/linuxthreads -L/usr/lib{,64}/linuxthreads
way to build LinuxThreads statically linked programs and/or
dynamically linked programs which can run against LinuxThreads
too. The advantage is that newly built programs can use
the NPTL ABI additions which are not present in LinuxThreads
(e.g. pthread_[sg]etaffinity_np, pthread_barrierattr_setpshared,
pthread_condattr_[sg]etclock, pthread_attr_[sg]etaffinity_np,
pthread_timedjoin_np, pthread_tryjoin_np and the new
__attribute__((cleanup)) based pthread_cleanup_{push,pop})
and that LinuxThreads really stays as a compatibility only
library.
The switch causes three important changes:
1) statically linked programs, no matter whether threaded or not,
will now require a NPTL capable kernel (one from RHL 9, RHEL3,
FC1, FC2 or any 2.6.x kernel should be enough), dynamically linked
programs using -lpthread in some cases as well (e.g. if they are using
the functions present in NPTL but not in LinuxThreads)
2) while previously blindly setting LD_ASSUME_KERNEL environment
variable at the beginning of large shell scripts around some
programs and sometimes even in /etc/profile.d/* often worked,
now the chances are lower (any time such shell script
runs a program which requires NPTL the program would fail
to run). LD_ASSUME_KERNEL should now be really only used
on the command line of the broken program which needs
LinuxThreads. E.g.
LD_ASSUME_KERNEL=2.4.19 /opt/FOOW/bin/barx --args xyz
3) NPTL has not been ported to i386, only i486+, x86_64,
ia64, ppc32, ppc64, s390, s390x, alpha, sh and sparcv9.
i386 (and sparc < v9) lacks atomic instructions powerful
enough for NPTL needs. Well, I have tried to port NPTL
to i386, http://sources.redhat.com/ml/libc-hacker/2004-05/msg00019.html,
but that port is severely limited and maintaining two
different IA32 ports would be too much work.
So for NPTL by default we need a i486-*-linux build of
glibc at least (well, it can still use
-march=i386 -mtune=pentium4, -march=i486 -mtune=pentium4
wouldn't make much difference).
This means though that almost no FC3 programs can run
on vanilla i386{SX,DX} CPUs. Is this a problem to anyone?
Fedora Core installer will certainly not install on i486
either, but if rpms from FC3 are used by RULE project...
There have been some i486+ only instructions accidentally
used in the past in many C++ programs (from libstdc++-v3
headers) and apparently nobody noticed this in RHL or
Fedora, so I assume not really many people are attempting
to revive their i386 boxes.
Now, the question is, as at least all statically linked programs
built on Fedora Core 3 and many dynamically linked ones will require
i486+ atomic instructions (xaddl, cmpxchgl), if we should change
rpm architecture of FC3 rpms or not.
One alternative is just change the definition of .i386.rpm
to be "can run on i386{SX,DX} only with XADD/CMPXCHG emulation
in the kernel [1] or any i486+" (and I must say I'm most inclined
to this). The corresponding rpmrc flags would be:
optflags: i386 -O2 -g -march=i386 -mtune=pentium4 -m32
optflags: i486 -O2 -g -march=i486 -m32
optflags: i586 -O2 -g -march=i586 -m32
optflags: i686 -O2 -g -march=i686 -mtune=pentium4 -m32
optflags: athlon -O2 -g -march=athlon -m32
but i386.rpm's would be allowed to contain xaddl/cmpxchgl instructions.
Another alternative is to change all rpms in FC3 which are .i386.rpm
in FC2 to .i486.rpm, with rpmrc:
optflags: i386 -O2 -g -march=i386 -m32
optflags: i486 -O2 -g -march=i486 -mtune=pentium4 -m32
optflags: i586 -O2 -g -march=i586 -m32
optflags: i686 -O2 -g -march=i686 -mtune=pentium4 -m32
optflags: athlon -O2 -g -march=athlon -m32
Using .i586.rpm's wouldn't buy us anything (-march=i586 -mtune=pentium4
is almost equivalent to -march=i486 -mtune=pentium4 and not
many programs really use cmpxchg8b instructions (which is not
even generated by GCC)) and moving the low bar to
.i686.rpm (note, i686 for GCC/rpm means i686 with X86_FEATURE_CMOV)
is probably too early for Fedora Core (there are still too many
VIA CPUs without cmov and even some Pentium's in use).
Jakub
