On Thu, Dec 13, 2018 at 10:33:48PM +0200, Efraim Flashner wrote: > On Thu, Dec 13, 2018 at 12:03:59AM -0500, Mark H Weaver wrote: > > Hi Efraim, > > > > I'm curious about this commit of yours from April 2017: > > > > --8<---------------cut here---------------start------------->8--- > > commit 5c7815f205e9164d4b82378de91bee7a65bcfbcb > > Author: Efraim Flashner > > Date: Mon Apr 10 05:20:09 2017 +0300 > > > > gnu: gcl: Build with gcc@4.9. > > > > * gnu/packages/lisp.scm (gcl)[native-inputs]: Add gcc@4.9. > > --8<---------------cut here---------------end--------------->8--- > > > > Do you remember why you did this? There's no explanation in the > > comments, nor in the commit log, nor in the 'bug-guix' or 'guix-devel' > > email archives from around that time. > > > > I'd like to remove it, and I've verified that on x86_64-linux, GCL > > builds successfully with the default compiler. > > > > In general, it would be good to include comments with rationale for > > workarounds like this, so that we have some idea of when the workaround > > can be removed, and what tests we must do to ensure that the original > > problem has been addressed. > > > > Thanks, > > Mark > > I looked through the commits and I'm not sure why I added gcc@4.9. When > did we change our default gcc from 4.9 to 5? I've made one attempt so > far at building on aarch64-linux without gcc@4.9 and I got a core-dump > but I haven't built it recently to see if it does that as-is. > > I'll take a closer look at it and try to see what's up. > I tried compiling gcl with gcc@7 also and it still failed on aarch64. The closest I have to a clue is that Debian's rule file has commented out to use gcc@4.6, so I'm guessing that following our upgrade to building with gcc@5 the package broke and it worked for a time with gcc@4.9. Since it fails to build in any case on aarch64 and building with gcc@5 doesn't cause any problems I'll go ahead and remove it. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted