On Sat, Apr 25, 2009 at 9:15 PM, Allan McRae <allan@archlinux.org> wrote:
Dan McGee wrote:
On Sat, Apr 25, 2009 at 2:47 PM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Allan McRae wrote:
Hi all,
The gcc-4.4.0 toolchain rebuild is now in [testing]. Here is a rough ChangeLog:
Awesome, Thanks I will build some things in a chroot, to see how it behaves.
glibc:
One note here, (low priority): in the ".install" post_upgrade() there is a line "init u". If glibc is installed in a chroot and don't have sysvinit package, because isn't needed, when glibc is upgrading will show a warning about can't execute init, so you can replace this line with a "[ -x /sbin/init ] && /sbin/init u" ?
I will push this to svn to be fixed in the next release.
And a question: why still support older kernels from 2.6.16?, considering that minimal kernel that udev support is 2.6.22, maybe can change the line --enable-kernel=2.6.16 with a superior version >= 2.6.22
From glibc manual: "This option is currently only useful on GNU/Linux systems. The version parameter should have the form X.Y.Z and describes the smallest version of the Linux kernel the generated library is expected to support. The higher the version number is, the less compatibility code is added, and the faster the code gets."
It might be worth bumping this up a bit, although not to the current kernel version. I think 2.6.22 is a wise choice. If you take a look at sysdeps/unix/sysv/linux/kernel-features.h, you can see that moving to 2.6.22 would enable the __ASSUME_PSELECT, __ASSUME_PPOLL, __ASSUME_ATFCTS, __ASSUME_SET_ROBUST_LIST, __ASSUME_FUTEX_LOCK_PI, __ASSUME_PRIVATE_FUTEX, and __ASSUME_UTIMENSAT options, which cut down on some unnecessary glibc workaround code.
Hmmm... I thought about bumping this to 2.6.18 this time round (based on nothing better that when good kernel headers became available) but decided not to as 2.6.16 is still widely used given it had a backport branch open for a long time (and maybe still does?).
I guess what I think the decision comes down to is: Are the speed gains from this actually noticeable? I'm skeptical but there are a fair number of workarounds removed doing that so maybe they are.
I'd like to see what happens when running our current userspace with a 2.6.16 kernel...do we have anyone out there that has done so recently? The last threads I could find on this issue were circa 2007, so things may have changed quite a bit since then. -Dan