#<LIBRARY LIBZ> does not have a known shared library file path.

[iamFIREcracker]

Hey,

I am getting the error mentioned in the title when trying to use deploy with my a CLI application of mine.

For reference, here is the complete stack trace when the error is signaled:

 ==> Running load hooks.
 ==> Gathering system information.
ensure-library #<LIBRARY LIBZ>
   -> Will load the following foreign libs on boot:
      NIL
 ==> Deploying files to /Users/matteolandi/my-env/opt/ap/bin/
ensure-library LIBZ
ensure-library #<LIBRARY LIBZ>
ensure-library #<LIBRARY LIBZ>
While evaluating the form starting at line 27, column 0
  of #P"/Users/matteolandi/my-env/opt/ap/build/build.lisp":

debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {10016800A3}>:
  #<LIBRARY LIBZ> does not have a known shared library file path.
restarts (invokable by number or by possibly-abbreviated name):
  0: [PROVIDE-PATH                 ] Provide the path to the library manually.
  1: [CONTINUE                     ] Ignore and continue deploying.
  2: [REPORT-ERROR                 ] Print the error and continue running hooks.
  3: [RETRY                        ] Retry #<DEPLOY-OP > on #<SYSTEM "ap">.
  4: [ACCEPT                       ] Continue, treating
                                     #<DEPLOY-OP > on #<SYSTEM "ap"> as having
                                     been successful.
  5:                                 Retry ASDF operation.
  6: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the
                                     configuration.
  7:                                 Retry ASDF operation.
  8:                                 Retry ASDF operation after resetting the
                                     configuration.
  9: [RETRY                        ] Retry EVAL of current toplevel form.
 10:                                 Ignore error and continue loading file "/Users/matteolandi/my-env/opt/ap/build/build.lisp".
 11: [ABORT                        ] Abort loading file "/Users/matteolandi/my-env/opt/ap/build/build.lisp".
 12:                                 Ignore runtime option --load "build/build.lisp".
 13:                                 Skip rest of --eval and --load options.
 14:                                 Skip to toplevel READ/EVAL/PRINT loop.
 15: [EXIT                         ] Exit SBCL (calling #'EXIT, killing the process).

((FLET DEPLOY::FOREIGN-LIBRARIES :IN "/Users/matteolandi/quicklisp/dists/quicklisp/software/deploy-20220220-git/deploy.lisp") :DIRECTORY #P"/Users/matteolandi/my-env/opt/ap/bin/")
   source: (ERROR "~a does not have a known shared library file path." LIB)
0]

While here are some details about my environment:

$ make lisp-info
sbcl --noinform --quit \
                --load "build/info.lisp"
SBCL:2.2.5 on X86-64
...

 fixnum bits:62
To load "trivial-features":
  Load 1 ASDF system:
    trivial-features
; Loading "trivial-features"

features = (:RUNNING-LOCALLY :QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3
            :ASDF2 :ASDF :OS-MACOSX :OS-UNIX :NON-BASE-CHARS-EXIST-P
            :ASDF-UNICODE :X86-64 :GENCGC :64-BIT :ANSI-CL :BSD :COMMON-LISP
            :DARWIN :IEEE-FLOATING-POINT :LITTLE-ENDIAN :MACH-O
            :PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB
            :SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE :SBCL :UNIX)

To fix the problem on my env, all I had to do was link libz.dylib into the current project directly, or into any other of the well-known places, like:/usr/lib/, or /usr/local/lib/.

ln -s $(brew --prefix zlib)/lib/libz.dylib ./

Done.

Well...not satisfied with the solution I started digging a bit more and noticed that, even though *system-source-directories* seems to contain the correct entry for MacOS (i.e. "#p"/usr/local/Cellar/**/lib/"), DEPLOY (and UIOP in particular) fails to locate #P"/usr/local/Cellar/zlib/1.2.12/lib/libz.1.2.12.dylib" using #P"/usr/local/Cellar/**/lib/libz.dylib".

Here is what DEPLOY does, when trying to locate lib files:

(defun pathname-filename (path)
  (format NIL "~a~@[.~a~]"
          (pathname-name path) (pathname-type path)))

(defvar *source* #p"/usr/local/Cellar/**/lib/")
(defvar *path* #p"libz.dylib")
(defvar *filename* (pathname-filename *path*))
(defvar *file* (merge-pathnames *filename* *source*))

> (uiop:file-exists-p *file*)
NIL

I know the library is there, because if I pass *file* to DIRECTORY it would return the dylib file:

> (directory *file*)
(#P"/usr/local/Cellar/zlib/1.2.12/lib/libz.1.2.12.dylib")

So, is there something wrong with using wilds with pathnames? If so, why bother adding entries for these inside *system-source-directories*, if, as it turns out, it won't work as expected?

Thanks,
M.