Re: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

older
[arch-general] Done! Website move...

Gerardo Exequiel Pozzi

25 Apr 2009 25 Apr '09

9:47 p.m.

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:

...

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

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

...

binutils: - add upstream patch to improve -Wl,--as-needed usage

Excelent!

...

Allan

Thanks in advance. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Show replies by date

Dan McGee

25 Apr 25 Apr

10:53 p.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

On Sat, Apr 25, 2009 at 2:47 PM, Gerardo Exequiel Pozzi 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

Gerardo Exequiel Pozzi

11:41 p.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

Dan McGee wrote:

...

On Sat, Apr 25, 2009 at 2:47 PM, Gerardo Exequiel Pozzi 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

Allan McRae

26 Apr 26 Apr

4:15 a.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

Dan McGee wrote:

...

On Sat, Apr 25, 2009 at 2:47 PM, Gerardo Exequiel Pozzi 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

Dan McGee

4:42 a.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

On Sat, Apr 25, 2009 at 9:15 PM, Allan McRae wrote:

...

Dan McGee wrote:

...
On Sat, Apr 25, 2009 at 2:47 PM, Gerardo Exequiel Pozzi 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

Thomas Bächler

11:27 a.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

Allan McRae schrieb:

...

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?).

2.6.27 will also be maintained for a few years now (no reference, I read this on lkml in a comment). I think among the Arch userbase, virtually nobody uses anything older than 2.6.27. We always announce to be "bleeding-edge", so IMO there should be no problem in supporting newer kernels only.

...

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.

The resulting code will probably be cleaner. I am always in favour of dropping legacy support. To everyone reading this: Do you use an exceptionally old kernel (say, older than 2.6.27) on Arch and why? Or do you know anyone who does?

Pierre Schmitz

11:33 a.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

Am Sonntag, 26. April 2009 11:27:29 schrieb Thomas Bächler:

...

I think among the Arch userbase, virtually nobody uses anything older than 2.6.27. We always announce to be "bleeding-edge", so IMO there should be no problem in supporting newer kernels only.

So those who use older kernels (why ever) just need to recompile glibc with their favourite settings? That would be acceptable imho. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de

Jan de Groot

1:27 p.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

On Sun, 2009-04-26 at 11:33 +0200, Pierre Schmitz wrote:

...

Am Sonntag, 26. April 2009 11:27:29 schrieb Thomas Bächler:

...
I think among the Arch userbase, virtually nobody uses anything older than 2.6.27. We always announce to be "bleeding-edge", so IMO there should be no problem in supporting newer kernels only.

So those who use older kernels (why ever) just need to recompile glibc with their favourite settings? That would be acceptable imho.

So, if I'm updating from a system that hasn't been rebooted for half a year or so, I won't even get a chance to do so: pacman -S glibc, wait a few minutes for the update, and then everything says: "FATAL: Kernel too old". Don't do it, this will break lots of systems.

Daenyth Blank

2:43 p.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

On Sun, Apr 26, 2009 at 05:27, Thomas Bächler wrote:

...

Allan McRae schrieb:

...
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?).

2.6.27 will also be maintained for a few years now (no reference, I read this on lkml in a comment).

I think among the Arch userbase, virtually nobody uses anything older than 2.6.27. We always announce to be "bleeding-edge", so IMO there should be no problem in supporting newer kernels only.

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

The resulting code will probably be cleaner. I am always in favour of dropping legacy support.

To everyone reading this: Do you use an exceptionally old kernel (say, older than 2.6.27) on Arch and why? Or do you know anyone who does?

Shared hosting sites use kernels as old as .24 iirc.

Dan McGee

4:19 p.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

On Sun, Apr 26, 2009 at 7:43 AM, Daenyth Blank wrote:

...

On Sun, Apr 26, 2009 at 05:27, Thomas Bächler wrote:

...
Allan McRae schrieb:

...
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?).

2.6.27 will also be maintained for a few years now (no reference, I read this on lkml in a comment).

I think among the Arch userbase, virtually nobody uses anything older than 2.6.27. We always announce to be "bleeding-edge", so IMO there should be no problem in supporting newer kernels only.

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

The resulting code will probably be cleaner. I am always in favour of dropping legacy support.

To everyone reading this: Do you use an exceptionally old kernel (say, older than 2.6.27) on Arch and why? Or do you know anyone who does?

Shared hosting sites use kernels as old as .24 iirc.

Slicehost provides me with a .24 kernel. Thus the reason the bump to 2.6.22 seemed acceptable to at least me, but going all the way to .27 will not work at all. -Dan

Gerardo Exequiel Pozzi

10:45 p.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

Thomas Bächler wrote:

...

Allan McRae schrieb:

...
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?).

2.6.27 will also be maintained for a few years now (no reference, I read this on lkml in a comment).

I think among the Arch userbase, virtually nobody uses anything older than 2.6.27. We always announce to be "bleeding-edge", so IMO there should be no problem in supporting newer kernels only.

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

The resulting code will probably be cleaner. I am always in favour of dropping legacy support.

To everyone reading this: Do you use an exceptionally old kernel (say, older than 2.6.27) on Arch and why? Or do you know anyone who does?

Personally (as "desktop" user), I use linux-2.6.27.21 without any patches (I am in planing to jump directly to 2.6.30.2 when it is released), with my custom config. It is the only piece of software that I maintain some respect and do not update after a certain time. In my oponión as I said before, I think this is the perfect upload limit of 2.6.16 to 2.6.22, which is the minimum version that udev needs to run. Unless there is any user who uses an old udev, or use a static /dev. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Gerardo Exequiel Pozzi

27 Apr 27 Apr

6:11 a.m.

New subject: [arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

Gerardo Exequiel Pozzi wrote:

...

Thomas Bächler wrote:

...
Allan McRae schrieb:

...
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?).

2.6.27 will also be maintained for a few years now (no reference, I read this on lkml in a comment).

I think among the Arch userbase, virtually nobody uses anything older than 2.6.27. We always announce to be "bleeding-edge", so IMO there should be no problem in supporting newer kernels only.

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

The resulting code will probably be cleaner. I am always in favour of dropping legacy support.

To everyone reading this: Do you use an exceptionally old kernel (say, older than 2.6.27) on Arch and why? Or do you know anyone who does?

Personally (as "desktop" user), I use linux-2.6.27.21 without any patches (I am in planing to jump directly to 2.6.30.2 when it is released), with my custom config. It is the only piece of software that I maintain some respect and do not update after a certain time.

In my oponión as I said before, I think this is the perfect upload limit of 2.6.16 to 2.6.22, which is the minimum version that udev needs to run. Unless there is any user who uses an old udev, or use a static /dev.

Another side note: if a user tries to build Linux <= 2.6.24.4 (defconfig) with GCC 4.3.3 will fail, Linux <= 2.6.25 (defconfig) fails with GCC 4.4.0 And Linux >= 2.6.25 (allmodconfig) builds OK with GCC 4.4.0. Of course, this is unrelated if some have already runing these old kernels in the system. Slackware and Debian support minimun Linux 2.6.18, Frugalware 2.6.24 and Gentoo... 2.6.9 PS: Allan Linux 2.6.16 is unmantained, the last version .62 is from July 2008. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

5486

Age (days ago)

5488

Last active (days ago)

List overview

Download

11 comments

7 participants

participants (7)

Allan McRae
Daenyth Blank
Dan McGee
Gerardo Exequiel Pozzi
Jan de Groot
Pierre Schmitz
Thomas Bächler