package.cpath is not searched

[Claus Andersen]

I am not good at this - but it seems like your module does not respect package.cpath? It works fine when the path is explicit.

Simple test - added module to Lua file:

local scrypt = require "resty.scrypt"

This fails and gives the log entry that libscrypt is not found:

2014/10/16 15:17:34 [error] 11542#0: *24 lua entry thread aborted: runtime error: /usr/local/openresty/lualib/resty/scrypt.lua:36: Shared object "libscrypt.so" not found, required by "nginx"

ngx.say(package.cpath) tells me:

/usr/local/openresty/lualib/?.so;./?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/openresty/luajit/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so

So everything should be good? /usr/local/lib/lua/5.1/?.so is listed as the third path (and the .so was placed there by gmake install). I verified from the unpriviledged account that runs nginx that I could access the .so file:

$ ls -l /usr/local/lib/lua/5.1/
total 52
-rwxr-xr-x  1 root  wheel  52373 Oct 15 17:31 scrypt.so

$ objdump -T /usr/local/lib/lua/5.1/scrypt.so | grep format
/usr/local/lib/lua/5.1/scrypt.so:     file format elf64-x86-64-freebsd

As stated in your readme I then modified /usr/local/openresty/lualib/resty/scrypt.lua

Changed: local scrypt = ffi_load("scrypt.so")
To: local scrypt = ffi_load("/usr/local/lib/lua/5.1/scrypt.so")

With the explicit path things works perfectly (on FreeBSD 10 amd64)!

So as far as I can tell (which is not much!) your third instruction is wrong?

1. Place scrypt.so in Lua's package.cpath

Am I missing something completely obvious?

[Aapo Talvensaari]

Thank you for reporting this. I will look at it the next week.

[Aapo Talvensaari]

So it seems (I have to either change documentation or the code, changing docs seems a right thing to do):

clib = ffi.load(name [,global])
This loads the dynamic library given by name and returns a new C library namespace which binds to its symbols. On POSIX systems, if global is true, the library symbols are loaded into the global namespace, too.

If name is a path, the library is loaded from this path. Otherwise name is canonicalized in a system- dependent way and searched in the default search path for dynamic libraries:

On POSIX systems, if the name contains no dot, the extension .so is appended. Also, the lib prefix is prepended if necessary. So ffi.load("z") looks for "libz.so" in the default shared library search path.
On Windows systems, if the name contains no dot, the extension .dll is appended. So ffi.load("ws2_32") looks for "ws2_32.dll" in the default DLL search path.

[Claus Andersen]

Cool. I will try to play with these monday.
On 18 Oct 2014 15:52, "Aapo Talvensaari" [e-mail] wrote:

So it seems (I have to either change documentation or the code, changing
docs seems a right thing to do):

clib = ffi.load(name [,global])
This loads the dynamic library given by name and returns a new C library
namespace which binds to its symbols. On POSIX systems, if global is true,
the library symbols are loaded into the global namespace, too.

If name is a path, the library is loaded from this path. Otherwise name is
canonicalized in a system-dependent way and searched in the default search
path for dynamic libraries:

On POSIX systems, if the name contains no dot, the extension .so is
appended. Also, the lib prefix is prepended if necessary. So ffi.load("z")
looks for "libz.so" in the default shared library search path.
On Windows systems, if the name contains no dot, the extension .dll is
appended. So ffi.load("ws2_32") looks for "ws2_32.dll" in the default DLL
search path.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[Aapo Talvensaari]

I modified the docs. Please reopen if this is still a problem.