2.6.0 + NPTL WORKING (for real this time)

(home)

OK, I’m a fool. When I installed stitch I accidental put “ntpl” in the use flags rather then “nptl”, no wonder things went off without a hitch. So, for the last few days I have been attempting to get a NPTL install process (from scratch) down. I’ve tried an experimental version of the livecd, which caused more headaches then it was worth (such as pickup up my SATA hard drive as SCSI and putting it under /dev/sda, only to have the install boot and get a kernel panic because it had moved back to /dev/hda - All the mean time I couldn’t see anything because I had forgotten to compile hi-res stuff into the kernel so I was getting garbage). There are many more stories, but I have blocked the from my mind so as to keep my self sane.

So, after several stuff ups and acts of nature (well, the new kittens managed to reset my machine during an important compile somehow, I was sleeping on the lab floor at the time) I think I am finally there. I was having some difficulties and so I decided to do things the ultimate hardcore way, I decided to bootstrap the system by hand (rather then use the scripts provided). I discovered that to get NPTL compiled into the core bits and pieces, you must be running a kernel that will support it at the time. Now, just for a bit of background, NPTL is only supported by the 2.6.x kernel sources (ignoring the Red Hat backports) and the Gentoo livecd which I was using at the time boots a 2.4.x kernel; hence my problem. So, the solution:

1. Edit the sys-kernel/linux-headers/linux-headers-2.6.0.ebuild file and add “x86″ to the KEYWORDS variable
2. Bootstrap the system with the bootstrap-2.6.sh (I did it by hand, but didn’t really need to).
3. Complete the install process as normal (emerge system et al.) MAKING SURE to install a 2.6.x kernel (I’m using gentoo-dev-sources, but I hear mm-sources is pretty nice)
4. Reboot that machine
5. Add “nptl” to you USE flags in make.conf
6. emerge glibc again (if you enter “emerge -pv glibc” you should see the “+nptl”)

I’m pretty sure that everything emerged to this point does not actually use nptl directly, so there is no need to recompile anything except glibc. However, if you are doing this on a pre-existing install there will probably be stuff that needs to be reemerged.

I also recompiled the kernel and rebooted (just to be safe).

Now I have the reward:

root@duffman tim # /lib/libc.so.6
GNU C Library stable release version 2.3.2, by Roland McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice).
Compiled on a Linux 2.6.0 system on 2004-01-10.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
NPTL 0.28 by Ulrich Drepper
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.

NPTL makes a big performance diff to Java apps, a big one, hence the main reason I installed it (and I wanted to be on the “cutting edge”). To tell ant to create the fedWS distributable takes around 20 seconds with Windows XP (and around 28 with my old 2.4.22 desktop). I just tested it with stitch (whom I have just recently fixed to use NPTL also) and it took 7 seconds. Nuf said.

Well, that’s all I can muster for now, I must get some sleep (been getting between 2 and 6 hours the last 3 nights, I should really go to bed earlier then 4/5). I’ve set the machine compiling Gnome and X (which usually takes about 6 hours) and just to give it some extra love, I tacked eclipse, firebird and samba on the end of that, so it should be going long enough to get a good sleep (I’m timing it, so I’ll have an actual number when I wake up - assuming nothing fails :P)


4 Responses to “2.6.0 + NPTL WORKING (for real this time)”

  1. Cameron Says:

    ” . . it took 7 seconds . . ”

    Imagine how much faster it would be if you used c!

  2. tim Says:

    A pox on you.

  3. TX Says:

    Didn’t the recent benchmarks show Java running faster than C anyway?

  4. tim Says:

    he was just baiting me :) And I do have benchmarks which show Java running faster then C, however, the problem is that while this may be true for the benchmarks, the actual performance in proper sized applications does lag behind from a speed perspective *performance wise*, development wise, well, there is no question there.