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

[Ludovic Courtès]

Efraim Flashner  skribis:

> On February 22, 2017 9:42:58 PM GMT+02:00, Efraim Flashner 
>  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  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 gcc@4.9 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      אפרים פלשנר
>>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 GCC@4.9 and gccgo, and gccgo@5 
> 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’.

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

[Efraim Flashner]

On February 22, 2017 9:42:58 PM GMT+02:00, Efraim Flashner 
 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  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 gcc@4.9 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      אפרים פלשנר
>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 GCC@4.9 and gccgo, and gccgo@5 failed 
as expected.

Unfortunately pushing this patch would result in a full rebuild on 
core-updates. Suggestions?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Efraim Flashner]

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  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 gcc@4.9 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      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

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

[Efraim Flashner]

On Tue, Feb 14, 2017 at 09:51:47AM +0100, Ludovic Courtès wrote:
> Danny Milosavljevic  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.

-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Danny Milosavljevic  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’.

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

[Danny Milosavljevic]

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

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

[Efraim Flashner]

* gnu/packages/gcc.scm (gcc)[arguments]: On aarch64 replace force libdir
to be lib and not lib64.
---
 gnu/packages/gcc.scm | 4 
 1 file changed, 4 insertions(+)

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 075642ebd..2bd630d5d 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -263,6 +263,10 @@ where the OS part is overloaded to denote a specific 
ABI---into GCC
 (("static char const sed_cmd_z\\[\\] =.*;")
  "static char const sed_cmd_z[] = \"sed\";"))
 
+  ;; Force Aarch64 libdir to be /lib and not /lib64
+  (substitute* "gcc/config/aarch64/t-aarch64-linux"
+(("lib64") "lib"))
+
   (when (file-exists? "libbacktrace")
 ;; GCC 4.8+ comes with libbacktrace.  By default it builds
 ;; with -Werror, which fails with a -Wcast-qual error in glibc
-- 
2.11.1