Couldn't execute "lib" during static-program-op

[Wilfredo Velázquez-Rodríguez]

On Windows 10 x64

This might be user error, but I haven't been successful in finding examples of :static-program-op, so I'm writing up a simple hello-world like:

hello-world.asd:

(defsystem #:hello-world
  :entry-point "hello-world:main"
  :components ((:file "hello-lisp")
               (:c-file "hello-c"))
  :defsystem-depends-on (#:cffi-grovel)
  :depends-on (#:cffi))

hello-lisp.lisp:

(defpackage #:hello-world
  (:use #:cl))

(in-package #:hello-world)

(cffi:defcfun ("hello_world" hello-world) :void)

(defun main ()
  (hello-world)
  0)

hello-c.c:

#include <stdio.h>

void hello_world() {
    printf("Hello, world!\n");
    fflush(stdout);
}

Then at the REPL:
CL-USER> (progn (asdf:load-system '#:cffi-grovel)
                (asdf:load-asd (truename "~/hello-world.asd"))
                (asdf:operate :static-program-op '#:hello-world))

I get the following:
Couldn't execute "lib": The system cannot find the file specified.
   [Condition of type SIMPLE-ERROR]

Looking through the sources I see it's trying to run the program lib with -nologo and some other options. However, I'm not sure where this program is supposed to be coming from. On my system, I have a lib program bundled with Visual Studio, but that program doesn't recognize options like -nologo, so I assume it's another. But I haven't been able to find out which.

Any help would be appreciated.

Thanks!

[Luís Oliveira (luismbo)]

On Thu, 13 Aug 2020 at 13:50, Wilfredo Velázquez-Rodríguez <
<email address hidden>> wrote:

> Looking through the sources I see it's trying to run the program lib
> with -nologo and some other options. However, I'm not sure where this
> program is supposed to be coming from. On my system, I have a lib
> program bundled with Visual Studio, but that program doesn't recognize
> options like -nologo, so I assume it's another. But I haven't been able
> to find out which.
>

Pinging Faré who may be able to give us a clue.

[Wilfredo Velázquez-Rodríguez (zulu-inuoe)]

FYI - Switching

             #+linux ,@`("ar" "rcsDT" ,output-file)
             #+windows ,@`("lib" "-nologo" ,(strcat "-out:" (native-namestring output-file)))

to

             #+(or linux windows) ,@`("ar" "rcsDT" ,output-file)

Seems to work, but I don't know what sort of expectation on toolchains CFFI has.

I get gcc errors later on, but I'm sifting through those.

[Luís Oliveira (luismbo)]

On Thu, 13 Aug 2020 at 16:00, Wilfredo Velázquez-Rodríguez <
<email address hidden>> wrote:

> Seems to work, but I don't know what sort of expectation on toolchains
> CFFI has.
>

 I suspect this feature is not often used on Windows. Doesn't this feature
need to be using the same toolchain used to build the Lisp compiler? In
general, I suppose it would be nice if CFFI could support both MINGW and
the Microsoft toolchains.

[Wilfredo Velázquez-Rodríguez (zulu-inuoe)]

It would be nice, but you're right - given SBCL OOTB only builds on MinGW I think it's reasonable CFFI only support that environment.
But as far as I'm aware there is no 'lib' program in that toolchain, is that right? I'm unfamiliar with most of these tools so I don't know what's conventionally used, but as I said, using `ar` as is done on Linux seems to work.

I can't conclusively say because I couldn't get it to go all the way through (trying again when I have time), and am still fuzzy about what exactly :static-program-op is doing under the hood.

[Luís Oliveira (luismbo)]

Right, though maybe ECL supports other toolchains, I'm not sure. And you could use the Microsoft toolchain for things other than static-program-op, possibly.

But, I agree with you, if we're going to only support one toolchain, MinGW is a better bet at this point.

Thanks for looking into static-program-op on Windows, keep us posted!