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

[Dan McGee]

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