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
Once upon a time Wednesday 19 May 2004 10:24 pm, Jakub Jelinek wrote: <snip>
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
i like the second option. i still use a pentium 166 as a router and i have a cyrix based system here which needs i586 kernel and until recently also used a k6-2 system needing i586 kernel also. since there is not really any gain from i486 to i586 id go with the i486 i know of some people who use i486's for firwalls. just my AU$0.02 soon to be US$0.02
Dennis
Hi Jakub,
I'd like to make NPTL the default threading library for FC3, as a step in phasing out LinuxThreads.
This means though that almost no FC3 programs can run on vanilla i386{SX,DX} CPUs. Is this a problem to anyone?
It's always a bit sad to have to give up compatibility, but otoh most boxes with i386 CPUs (including Cyrixes and WinChips) are usually not that well equiped to run the bloated releases we have today anyway.
Actually i386 support has already been effectively discontinued (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078). Time to start looking for some small footprint distros for such boxes.
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.
Well, at least one person has tried to :) .
Another alternative is to change all rpms in FC3 which are .i386.rpm in FC2 to .i486.rpm, with rpmrc:
Although it might appear a bit funny at first I think this is the most consequent solution. If it's not i386 compatible it shouldn't be called so.
Also have a look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933 .
Leonard.
On Wed, May 19, 2004 at 02:55:08PM +0200, Leonard den Ottolander wrote:
It's always a bit sad to have to give up compatibility, but otoh most boxes with i386 CPUs (including Cyrixes and WinChips) are usually not that well equiped to run the bloated releases we have today anyway.
Winchip is pentium equivalent, cyrix above cyrix 386 is 486 equivalent. We are talking Intel i386 (double sigma, DX, SX) [pre double sigma not supported anyway) AMD and Cyrix clones of the above Probably Nexgen 5x86 [lacks kernel side read faulting]
Hi Alan,
Winchip is pentium equivalent, cyrix above cyrix 386 is 486 equivalent.
No. Maybe almost but not exactly. Both (Cyrix P166 and WinChip 200) miss tsc and cmov. The missing tsc is what causes rpm to fail. Missing cmov might cause other problems. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 .
Leonard.
On Wed, May 19, 2004 at 03:36:27PM +0200, Leonard den Ottolander wrote:
Hi Alan,
Winchip is pentium equivalent, cyrix above cyrix 386 is 486 equivalent.
No. Maybe almost but not exactly. Both (Cyrix P166 and WinChip 200) miss tsc and cmov. The missing tsc is what causes rpm to fail. Missing cmov might cause other problems. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 .
Well, missing cmov is not a problem for NPTL (and shouldn't be for rpm in FC3 either). The thing is just that there has been only i686 NPTL built in FC1/2 and RHL9/RHEL3. And rpm linked against NPTL, therefore it used cmov. When there is a i486 NPTL build, rpm can link against that.
Jakub
On Wed, May 19, 2004 at 03:36:27PM +0200, Leonard den Ottolander wrote:
Hi Alan,
Winchip is pentium equivalent, cyrix above cyrix 386 is 486 equivalent.
No. Maybe almost but not exactly. Both (Cyrix P166 and WinChip 200) miss tsc and cmov. The missing tsc is what causes rpm to fail. Missing cmov might cause other problems. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 .
tsc is pentium and higher. cmov is pentium pro and higher. RPM is just broken according to that bug.
Hi Alan,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 .
tsc is pentium and higher. cmov is pentium pro and higher. RPM is just broken according to that bug.
And if you look closer it wont be fixed. "Marching orders". Hence my conclusion i386 CPUs are already no longer supported on Fedora Core. According to your statement the same is true for anything < pentium. This would mean we could move to i586 as the minimal architecture just as well.
Leonard.
On Thu, May 20, 2004 at 12:36:43AM +0200, Leonard den Ottolander wrote:
And if you look closer it wont be fixed. "Marching orders". Hence my conclusion i386 CPUs are already no longer supported on Fedora Core. According to your statement the same is true for anything < pentium. This would mean we could move to i586 as the minimal architecture just as well.
tsc is not available in some i686 or higher systems and doesn't do what anyone expects on things like big summit boxes (IBM x440 and the like)
Hi Alan,
tsc is not available in some i686 or higher systems and doesn't do what anyone expects on things like big summit boxes (IBM x440 and the like)
Which i686 architectures would that be? The big boxes are not relevant for this bug as inclusion of the offending code is based on an #ifdef __i386__. Are you arguing this bug should be reopened? Or is the conclusion that tsc is the culprit wrong?
Leonard.
Alan Cox wrote:
tsc is pentium and higher. cmov is pentium pro and higher. RPM is just broken according to that bug.
RPM ever since RH9 has been shipping with an internalized db4, I think for the purpose of working without NPTL. It works great, and I have used it every day since RH9's beta. In fact fedora.us-buildsys relies on it for all RH9 through FC2 packages.
Warren Togami wtogami@redhat.com
Hello Warren,
RPM ever since RH9 has been shipping with an internalized db4, I think for the purpose of working without NPTL. It works great, and I have used it every day since RH9's beta.
The built in db4 obviously is not the reason why rpm fails on anything less than a pentium. NPTL code inside rpm is. Read the bug report for details.
Leonard.
On Wed, 2004-05-19 at 13:55, Leonard den Ottolander wrote:
This means though that almost no FC3 programs can run on vanilla i386{SX,DX} CPUs. Is this a problem to anyone?
It's always a bit sad to have to give up compatibility, but otoh most boxes with i386 CPUs (including Cyrixes and WinChips)
nitpick: the winchips were 586's, and should still run in a really low-end role. (just don't try running stuff like OO.o on them).
Dave
On Wed, 2004-05-19 at 14:24, Jakub Jelinek wrote:
This means though that almost no FC3 programs can run on vanilla i386{SX,DX} CPUs. Is this a problem to anyone?
Red Hat 9 was almost impossible to run decently on an i386-class machine due to lack of resources (mainly, the CPU). I sill have a 386DX/20 lying around, but it's simply unable to run anything newer than a 2.0, or 2.2-kernel based distribution.
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.
As I said before, EnGarde Secure Linux 1.0, which is 2.2-kernel-based, is what that machine can run at most.
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
I like this one. Go for it!
On Wed, May 19, 2004 at 08:24:35AM -0400, Jakub Jelinek wrote:
- 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)
When compiling static programs, one can always specify the location for the LT version. A section about the change in the release notes for the next FC version could have that information.
- 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
I'd rather be able to set flags on program files with that information: # setth lt_fs $(find /opt/java -type f -perm -u+x)
So there would be no need for individual users to know when a LD_ASSUME_KERNEL is needed, no need for sysadmins to create wrapper scripts, and no need to go through an obscure shell script finding the place where the final binary is called.
- NPTL has not been ported to i386, only i486+, x86_64,
...
This means though that almost no FC3 programs can run on vanilla i386{SX,DX} CPUs. Is this a problem to anyone?
I don't see myself in need to run FC3 programs on i386. However, as long as it's possible to do a CC="gcc -I/usr/include/linuxthreads -L/usr/lib{,64}/linuxthreads" rpmbuild --rebuild package.src.rpm, I'll be able to.
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.
Well, if those .i386.rpms can't run in a i386, then they shouldn't be named as such. :)
I'd go with the second alternative.
Regards, Luciano Rocha
On Wed, May 19, 2004 at 08:24:35AM -0400, Jakub Jelinek wrote:
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).
I think that if the time isn't FC3, it's very very soon after that. I know that there are many older systems out there, and that they can have a very useful life under Linux, but there are other more focused, lightweight distributions which might be better choices there. Perhaps there could even be a Fedora Lite project branch, if there's enough interest. (And if there's not enough interest, that says something too.)