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