libvips / lua-vips

Lua binding for the libvips image processing library
MIT License
125 stars 10 forks source link

The specified module couldn't be found #43

Closed Bilal2453 closed 2 years ago

Bilal2453 commented 2 years ago

The ffi.load("libvips-42.dll") call reports on Windows 10, LuaJIT 2.1.0-beta3. I've been following the instructions in the README of installing this, after installing libvips (By unzipping, and putting its bin directory in the user PATH).

As a confirmation, trying to manually do ffi.load "libglib-2.0-0.dll" (which is indeed in the same bin directory as libvips) works just fine, returning the expected userdata.

The pre-built binaries I have tried where:

All of those resulted in the reported error on require "vips". In addition to that, I have tested manually loading libvips in the following ways:

Lastly, I am not quite sure if it is my setup problem (although I am sure I am following the steps right) or somehow with the libvips binary itself. lua-vips works just fine under Linux with LuaJIT 2.1.0-beta3. I got my lua-vips directly through git cloning it on both Linux and Windows.

jcupitt commented 2 years ago

Hi @Bilal2453,

That sounds very weird. I've never tried lua-vips on windows, but I'd think it'd work. Those libvips zips work fine with python on windows (I tested them just a few days ago).

Where did you get the luajit binary?

Bilal2453 commented 2 years ago

After a lot of debugging and experimenting, I have to say I am embarrassed of myself.

I found my oversights out, and it is mainly me testing and editing PATH without re-opening my command prompt (so it never updates to new PATH. I am too used to Unix apparently), as well as using dynamic builds while only having the bin directory (although I tested static ones too and didn't work because again didn't reopen my command prompt causing confusion). Multiple factors have played here (and I blame windows for it 😂), yet, there is still some weirdness going around.

Interestingly, using an absolute path to the dll will always load the version in the PATH no matter what was the path (I suppose it is a luajit thing, only taking dll name out of the path) causing more confusion to me here and is opposite of what Windows LoadLibrary documentations advice doing. I will have to find some workaround to that for my little project.

Thank you @jcupitt for your valuable time and help. And sorry for my confusion here!

jcupitt commented 2 years ago

Oh heh, don't worry, I've done much dumber things. Glad it's working.