[arch-dev-public] binutils-2.20 toolchain rebuild in [testing]

[Allan McRae]

Eric Bélanger wrote:
> On Mon, Oct 19, 2009 at 4:11 PM, Jan de Groot <jan at jgc.homeip.net> wrote:
>   
>> On Mon, 2009-10-19 at 15:45 -0400, Eric Bélanger wrote:
>>     
>>> On Mon, Oct 19, 2009 at 10:07 AM, Allan McRae <allan at archlinux.org> wrote:
>>>       
>>>> Hi
>>>>
>>>> The binutils-2.20 toolchain rebuild is in [testing] for i686.  I will do
>>>> the x86_64 rebuilds in the next day or two.  A summary of changes:
>>>>
>>>> kernel-headers - bump to latest
>>>>
>>>> binutils - bump to latest
>>>>
>>>> glibc - grab upstream patchset for proposed future stable release, fix
>>>> overflow bug (FS#16253), patch to build against latest binutils
>>>>
>>>> gcc - bump to latest, use package spitting (gcc-libs, gcc, gcc-fortran,
>>>> gcc-objc), move static libraries from gcc-libs to gcc, add gcc-ada
>>>> package, do not run fixincludes during build.
>>>>
>>>> I will call for a signoff a few days after getting the x86_64 builds done.
>>>>
>>>> Allan
>>>>
>>>>         
>>> FYI, kernel-headers would be a candidate for the any arch. However, if
>>> you do the switch, then you'll need to release the toolchain for both
>>> arches at the same time otherwise it might break some stuff.
>>>       
>> I wouldn't be too sure about that. Have you diffed extracted tarballs of
>> kernel-headers for both architectures and did it return only .PKGINFO
>> related differences?
>> Reason for asking this is the /usr/include/asm directory. Though these
>> files are just stupid header files, the asm directory is usually taken
>> from architecture-specific includes.
>>
>>
>>     
>
> I had the same thought and had done a diff for
> kernel-headers-2.6.30.5-1.  Only the .PKGINFO were different.  It's
> possible that this will be changed for future updates though.  Maybe
> it would be safer to keep it arch dependent.
>   

I have considered this and did a diff on the packages and came to same 
conclusion as you.   But I did not want to assume that this will always 
be the case...  screwing up the toolchain is not something I want to do!

Also, it is not a real "any" package.  I believe the package is 
different on e.g. ppc (asm stuff that Jan mentioned), although I have 
not checked...

So, I think I will leave this package as is.

Allan