I wonder if I have missed a step in the installation of the prerequisites ?
Here is a copy of the ticket:
I guess, in order to use @[Link("webview")] ( rather than @[Link(ldflags: "#{__DIR__}/webview.lib")] ), webview.lib is supposed to be installed in some standard locations for libraries under Windows 10 or 11 (the equivalent of /usr/local/lib under Linux).
However, in my case, running the install.bat script from webview/script at master · webview/webview · GitHub did build said library webview.lib locally, but did apparently not copy it to a (standard) location which would be accessible by default to Crystal via a simple @[Link(“webview”)] , this is basically why the shards install fails and why I had to resort to the alternative : @[Link(ldflags: "#{__DIR__}/webview.lib")] for Crystal to be able to access Webview (see : Crystal App with Webview for dummies (template)).
I guess, in order to use @[Link("webview")] ( rather than @[Link(ldflags: "#{__DIR__}/webview.lib")] ), webview.lib is supposed to be installed in some standard locations for libraries under Windows 10 or 11 (the equivalent of /usr/local/lib under Linux).
you need to locate which folder crystal is using for the shared library files using crystal env CRYSTAL_LIBRARY_PATH. you can put your .lib file there.
personally I think relative path works, too, because you only need it for compiling.
You are right, @[Link("webview")] works if you copy lib file, that’s why i added copy webview\dll\x64\webview.lib to <your crystal installation>\lib in installation steps (webview/README.md at master · naqvis/webview · GitHub)
The trick with @[Link(ldflags: "#{__DIR__}/webview.lib")] is nice though, i didn’t know about it. I’m still not sure which way is better. Currently i just copy all .lib that i generate to crystal\lib.
I think that ideal way is to don’t use lib files at all - they don’t carry any info that isn’t present in .dll, so they are just additional burden. Under linux, crystal links with .so without additional files, that’s why i believe that it should do the same on Windows.
Apparently in Go, it is now possible to do exactly that : bind Go code to DLLs using Purego : purego package - github.com/ebitengine/purego - Go Packages (bypassing the necessity to separately use a .lib archive for development and a .DLL file for distribution). I don’t know if the same is possible at this stage in Crystal.