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" ?
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.
If we do bump this, it is a newsworthy item to let users know that our userspace is only compatible with kernels 2.6.22 and up after this upgrade- this is important for people running in a Xen context among other things with a kernel provided by someone else.
Sidenote: * Bumping to 2.6.23 would add __ASSUME_FALLOCATE * Bumping to 2.6.24 would add __ASSUME_ADJ_OFFSET_SS_READ * Bumping to 2.6.27 would add assumes for CLOEXEC, NONBLOCK, PIPE2, and PACCEPT
-Dan
Hi Dan, thanks for your response. Some time ago I had investigated this: The "documentation vs source" is a bit confusing, it talks that the option "enable-kernel" will drop support for runing glibc in older kernels, but don't talk about enabling new features. But when reading the source "apparently" the option "enable-kernel" not only drop old code, also add new features, but, look this... (this is the glibc-2.9-4 from [core]) $ nm /lib/libc-2.9.so | grep have_fallocate 001463ac b __have_fallocate $ nm /lib/libc-2.9.so | grep have_o_cloexec 001463b0 b __have_o_cloexec etc. And can use this , so if i am not wrong, as said the documentation, this option only drop support for older kernels not enables new code. Doing a bit deep research... For example in the case of the O_CLOEXEC for the open() (from sysdeps/unix/opendir.c) #ifdef __ASSUME_O_CLOEXEC # define check_have_o_cloexec(fd) 1 #else static int check_have_o_cloexec (int fd) { if (__have_o_cloexec == 0) __have_o_cloexec = (__fcntl (fd, F_GETFD, 0) & FD_CLOEXEC) == 0 ? -1 : 1; return __have_o_cloexec > 0; } #endif So in each call for open() with a O_CLOEXEC flag, will check if the current kernel suport it, then use it. This is that the enable-kernel do, just remove these runtime-checks for features. Cheers, -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D