On February 22, 2017 9:42:58 PM GMT+02:00, Efraim Flashner <efraim@flashner.co.il> 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 <dannym@scratchpost.org> 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.

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.