[bug#71925] [PATCH 2/2] gnu: klee: Build with klee-uclibc support.

[Liliana Marie Prikler]

Am Sonntag, dem 07.07.2024 um 13:24 +0200 schrieb Sören Tempel:
> Hi Liliana,
> 
> Thanks a lot for the quick feedback, responses below.
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> > The leading colon is pointless here, since you're doing an "="
> > assign.
> 
> Good catch! I can fix this in a patch revision.
> 
> > More importantly, can we make this a search path?
> 
> I don't think so as it's not a colon separated search path, it can
> only point to a single directory; hence, I assumed that wrap-program
> is more appropriate here.
Fair enough.

> > Can we use search-input-file for this and dirname our way up?
> 
> The input file that we are looking for here is called libc.a, I am
> not
> sure what the benefit of using search-input-file is, but I personally
> think something along the lines of `(dirname (search-input-file
> %build-inputs "/lib/libc.a"))` is less readable then `#$klee-uclibc`
> but I can definitely change this if you want me to :)
> 
> > Is this only distributed as an .a file or could we make a .so out
> > of it?
> 
> This is only distributed as a .a, not as a shared object. In fact,
> KLEE also doesn't not link against this library at all and instead
> converts it to an LLVM .bca file (shipped in
> /lib/klee/runtime/klee-uclibc.bca)
> during build. This file is then used directly by KLEE's symbolic LLVM
> interpreter to execute code utilizing libc functions. Hence, klee-
> uclibc is also not a propagated input for the klee package.
> 
> Let me know if I should send a revision, would love to get this
> merged.
Can we make it so that it uses the file directly instead of inferring
the name?  Then we could install klee-uclibc to, say
"/lib/klee/uclibc.a" and reference it in this build by said file name.

Cheers