On Sat, Apr 25, 2009 at 9:15 PM, Allan McRae <allan@xxxxxxxxxxxxx> wrote: > Dan McGee wrote: >> >> On Sat, Apr 25, 2009 at 2:47 PM, Gerardo Exequiel Pozzi >> <vmlinuz386@xxxxxxxxxxxx> 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
