ludo@gnu.org (Ludovic Courtès) writes:

> Kei Kebreau <kei@openmailbox.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi Kei,
>>>
>>> Kei Kebreau <kei@openmailbox.org> skribis:
>>>
>>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>>
>>>>> Kei Kebreau <kei@openmailbox.org> 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.

>
> Thanks,
> LUdo’.

P.S. Sorry for dragging this out for so long. I'm just trying to
understand how I can minimize the package size of GCL-dependent packages.