Re: [PATCH] gnu: Add varnish.

[Ricardo Wurmus]

Marius Bakke <address@hidden> writes:

> Ricardo Wurmus <address@hidden> 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.

Okay, thanks for explaining this.  About the problems with “as” and
“binutils” could you please also send a bug report to address@hidden

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net