Re: [PATCH 5/6] gnu: gcc: Force Aarch64 to use /lib.

[Ludovic Courtès]

Efraim Flashner <address@hidden> skribis:

> On February 22, 2017 9:42:58 PM GMT+02:00, Efraim Flashner <address@hidden> 
> wrote:
>>On Tue, Feb 14, 2017 at 09:51:20PM +0200, Efraim Flashner wrote:
>>> On Tue, Feb 14, 2017 at 09:51:47AM +0100, Ludovic Courtès wrote:
>>> > Danny Milosavljevic <address@hidden> skribis:
>>> > 
>>> > >> +              ;; Force Aarch64 libdir to be /lib and not /lib64
>>> > >> +              (substitute* "gcc/config/aarch64/t-aarch64-linux"
>>> > >> +                (("lib64") "lib"))
>>> > >> +
>>> > >
>>> > > I'd amend the comment to say why.
>>> > 
>>> > I think we should just skip this patch.  There’s no reason one
>>> > architecture should be treated different from the others in that
>>> > respect.
>>> > 
>>> > WDYT, Efraim?
>>> > 
>>> > Ludo’.
>>> 
>>> I don't think it should cause a problem either way. As far as I can
>>tell
>>> it doesn't make a difference to the software built further down the
>>> line.
>>> 
>>
>>Looks like I spoke too soon. I tried to build gccgo which failed at the
>>linking stage, since it turned out libgcc_s was in gccgo/lib64 and not
>>gccgo/lib. I then tried address@hidden and had a similar failure, the lib
>>files
>>were split between lib and lib64. Other than this patch (with a when
>>file-exists), the other idea is to change libdir in gcc.scm:86 to be
>>lib64 on aarch64.
>>
>>Unfortunately it looks like it'd cause a full rebuild on core-updates.
>>I'll test it overnight and see how it goes.
>>
>>-- 
>>Efraim Flashner   <address@hidden>   אפרים פלשנר
>>GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
>>Confidentiality cannot be guaranteed on emails sent or received
>>unencrypted
>
> As is, all of our GCC versions FTBFS on aarch64, except the versions used 
> during bootstrapping. This includes gccgo, but I haven't checked the other 
> 'special GCCs' to see if also affects them.
>
> With the above patch I was able to build address@hidden and gccgo, and 
> address@hidden failed as expected.
>
> Unfortunately pushing this patch would result in a full rebuild on 
> core-updates. Suggestions?

Given that ‘core-updates’ is still in the stage where we haven’t build
everything, you could push this ‘substitute*’ statement now IMO.

It’s pretty bad that software insists on using /lib64 down the road,
though.

Thanks,
Ludo’.