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.
Allan
