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

Allan McRae allan at archlinux.org
Sat Apr 25 22:15:02 EDT 2009


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.

Allan







More information about the arch-general mailing list