Ricardo Wurmus <rek...@elephly.net> writes:
>> + (add-after 'install 'wrap-binary
>> + (lambda* (#:key inputs outputs #:allow-other-keys)
>> + (let* ((out (assoc-ref outputs "out"))
>> + (varnishd (string-append out "/sbin/varnishd"))
>> + (PATH (string-append (assoc-ref inputs "binutils")
>> "/bin"))
>> + (LIBRARY_PATH (string-append (assoc-ref inputs "glibc")
>> "/lib")))
>> + ;; Add binutils to PATH so gcc finds the 'as' executable.
>> + (wrap-program varnishd
>> + `("PATH" ":" prefix (,PATH)))
>> + ;; Without this, we get an error such as "ld: cannot find
>> crti.o"
>> + ;; when compiling VCL.
>> + (wrap-program varnishd
>> + `("LIBRARY_PATH" ":" prefix (,LIBRARY_PATH)))
>> + #t))))))
>
> What is VCL? Is it always compiled from scratch at runtime?
VCL is the Varnish Configuration Language. The configuration file is
compiled at startup and when loading other configs at runtime. It is
also possible to have inline C code in the VCL.
>
>> + (inputs
>> + `(("binutils" ,binutils)
>> + ("gcc" ,gcc)
>> + ("glibc" ,glibc/linux)
>
> These three inputs are implicitly available as native inputs when using
> the gnu-build-system. Should varnish get a gcc-toolchain as a runtime
> input instead of these three separate inputs?
How would this work? Importing (gnu packages commencement) in web.scm
causes a bunch of "unbound variable" errors, probably due to conflicting
package names.
The 'as' requirement is actually from gcc, which should preferably be
compiled with '--with-as=<absolute-path-of-binutils-as>' (but does not
currently have binutils as input). I was surprised it used 'ld', which
probably works as a side effect after wrapping the binutils PATH.
The "LIBRARY_PATH" hack should possibly be fixed in binutils as well.
A custom toolchain sounds like a cleaner approach than these two
workarounds since those quirks can be worked out there, but not sure how
to go about making it.
signature.asc
Description: PGP signature
