Subject: Re: [bug#27628] [PATCH 3/3] gnu: maxima: Ensure gcc and binutils available at runtime.

From: Kei Kebreau <[email-masked]>
Date: Mon, 24 Jul 2017 12:08:37 -0400

Marius Bakke <[email-masked]> writes:

> Kei Kebreau <[email-masked]> writes:
>
>> [email-masked] (Ludovic Courtès) writes:
>>
>>> Kei Kebreau <[email-masked]> skribis:
>>>
>>>> [email-masked] (Ludovic Courtès) writes:
>>>>
>>>>> Hi Kei,
>>>>>
>>>>> Kei Kebreau <[email-masked]> skribis:
>>>>>
>>>>>> [email-masked] (Ludovic Courtès) writes:
>>>>>>
>>>>>>> Kei Kebreau <[email-masked]> skribis:
>>>>>>>
>>>>>>>> + ;; Ensure that Maxima will have access to GCC and its required
>>>>>>>> +               ;; components at runtime.
>>>>>>>
>>>>>>> In fact, if it’s an optional feature, it would be better to take GCC &
>>>>>>> co. from $PATH, because GCC is a huge dependency.  (Same for the gcl
>>>>>>> change.)
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>
>>>>>> I started on this patchset because Guix's Maxima cannot graph functions.
>>>>>> This feature relies on GCL's 'compile' function. The 'compile' function
>>>>>> seems to be a Common Lisp standard since at least the publication of the
>>>>>> CLtL2 standard. Maxima assumes (correctly) that this function is present
>>>>>> and relies on it for various base functionalities (compiling Maxima math
>>>>>> functions to compiled Lisp functions, graphing, etc.).
>>>>>
>>>>> Good point, ‘compile’ is standard CL.
>>>>>
>>>>> So yes, that alone is probably a good reason to keep references to GCC
>>>>> and Binutils (maybe add a comment explaining this.)  Sorry for holding
>>>>> it back!
>>>>>
>>>>>> I turns out that fixing the underlying issue with GCL removes the need
>>>>>> for GCC's presence at runtime, but binutils is still necessary due to
>>>>>> Maxima using the 'compile' function from GCL directly. This stems from
>>>>>> the GCC package not finding the binutils at runtime, i.e.
>>>>>>
>>>>>>     guix environment --pure --ad-hoc gcc -- gcc hello-world.c
>>>>>>
>>>>>> returns
>>>>>>
>>>>>>     gcc: error trying to exec 'as': execvp: No such file or directory
>>>>>>
>>>>>> but
>>>>>>
>>>>>>     guix environment --pure --ad-hoc gcc -- gcc -S hello-world.c
>>>>>
>>>>> You would need ‘gcc-toolchain’ rather than ‘gcc’ here.
>>>>>
>>>>> Thank you,
>>>>> Ludo’.
>>>>
>>>> Is gcc-toolchain a package one can use as an input? lisp.scm fails to
>>>> load properly when I use the commencement.scm module. Could this be due
>>>> to the circular dependency problem mentioned in the "Commentary" section
>>>> of commencement.scm?
>>>
>>> Yeah, rather use gcc/ld-wrapper/glibc as inputs to avoid this problem.
>>> ‘gcc-toolchain’ is rather for users.
>>
>> When I do this, GCL still gives me the
>>
>>   "gcc: error trying to exec 'as': execvp: No such file or directory"
>>
>> error if I don't wrap the binary with the binutils $PATH. The same has to
>> be done for Maxima. I'm trying to find a way to package GCL in such a
>> way that either (1) wrapping the GCL binary is unnecessary or (2)
>> wrapping the GCL binary and *only* the GCL binary is necessary for the
>> 'compile' function to work.
>
> This is because GCC does not retain an absolute reference to binutils'
> 'as'. I came across this too in:
>
> https://lists.gnu.org/archive/html/guix-devel/2016-11/msg01104.html
>
> If you have some cycles to spare, it could be interesting to try and
> use a GCC built with '--with-as=<absolute binutils path>'. E.g.
>
> (define-public gcc-with-as
>   (package
>     (inherit gcc)
>     (arguments
>       `(,@(substitute-keyword-arguments (package-arguments grub)
>             ((#:configure-flags flags ''())
>             `(cons (string-append "--with-as="
>                                   (assoc-ref %build-inputs "binutils")
>                                   "/bin/as")
>                    ,flags)))))))
>
> (define-public gcl
>   (package ...
>     (native-inputs `(("gcc" ,gcc-with-as)))))
>
> I've been meaning to try this a while, but you know... ;)

Based on playing around with this for a while, I'm concluding that the
core issue here is that the GCC binary from our GCC package for whatever
reason doesn't retain an absolute path to the GNU binutils binaries.

I have a hunch that Marius' solution could work, but I haven't been able
to get GCC to build with the necessary "--with-as" and "--with-ld" flags
yet. If no one has a better idea, I will push the 'binary-wrapping'
patches that at least get GCL and Maxima to compile things successfully.

Thanks to all involved,
Kei