lua entry thread aborted: runtime error: libnettle.so: cannot open shared object file: No such file or directory

[4217...@qq.com]

hi,

     I just want decode aes 256 ecb string.

     here is my code:

     local aes = require "resty.nettle.aes"

     local aes256 = aes.new("keykeykey")

     local msisdn = aes256:decrypt(ngx.decode_base64("YmON4n6EZDv+ZzdAyKaY3w=="))

     ngx.say(msisdn)

     I am using https://github.com/bungle/lua-resty-nettle

     however, i got an error:

2016/03/14 22:09:11 [error] 29778#0: *5 lua entry thread aborted: runtime error: libnettle.so: cannot open shared object file: No such file or directory

stack traceback:

coroutine 0:

        [C]: in function 'require'

        content_by_lua(nginx.conf:57):25: in function <content_by_lua(nginx.conf:57):1>, client: 127.0.0.1, server: , request: "POST / HTTP/1.1", host: "127.0.0.1:8080"

2016/03/14 22:09:11 [error] 29778#0: *6 lua entry thread aborted: runtime error: content_by_lua(nginx.conf:57):25: loop or previous error loading module 'resty.nettle.aes'

stack traceback:

coroutine 0:

     it sad cannot open shared object libnettle.so,,

 but i already put libnettle.so in /usr/local/openresty/lualib/

 I also can see cjson.so in that folder.  

can someone help me?  how to install  openresty with lua-resty-nettle ?

    

[Aapo Talvensaari]

Lualib is wrong path for FFI libs. libnettle.so/.dylib/.dll should be in system library path. This is how LuaJIT has always worked. Lualib dir is for C modules/wrappers implementing Lua C API. FFI bypassed Lua C API and uses libraries directly.

[Yichun Zhang (agentzh)]

Hello!

On Mon, Mar 14, 2016 at 11:30 AM, Aapo Talvensaari wrote:
> Lualib is wrong path for FFI libs. libnettle.so/.dylib/.dll should be in
> system library path. This is how LuaJIT has always worked. Lualib dir is for
> C modules/wrappers implementing Lua C API. FFI bypassed Lua C API and uses
> libraries directly.
>

Actually I'd recommend Lua FFI-based libraries to search the paths in
package.cpath as well :) For example, lua-resty-json uses this trick:

https://github.com/cloudflare/lua-resty-json

Regards,
-agentzh

[Aapo Talvensaari]

I have actually seen that trick. But I have been thinking that it is too clever and can cause other issues, like updating package through package manager, and trying to figure out what library the FFI binding actually uses. One in package.cpath or one in system path. Maybe it is not. It's really uncommon trick that I rarely see on other LuaJIT FFI bindings. And also, I think that if that trick is in place, it should try to find the lib with and without "lib" prefix. Just like LuaJIT does on system path. Also it seems that the trick implemented in lua-resty-json seems to follow *nix convention only, and it doesn't try to load .dylib or .dll files (are there others – and that could be a source of confusion as well?). I'm not sure it is worth it, and if it really is, then the right place to write it is directly in LuaJIT. Maybe OpenResty's fork of LuaJIT can search also on package.cpath, so that the trick is standard in OpenResty. Now people may follow incomplete (in my opinion) lua-resty-json trick and that may cause even more confusion that it might solve.

I'm not against it totally, but I'm not yet convinced of it either. It feels a bit hacky in its current form.

[Aapo Talvensaari]

Also what if you want to supply both FFI and C API version. Say xx.so and xx.so. The first one is the Lua C API version that you place in package.cpath and it works with both LuaJIT and PUC Lua. And the other goes to system path that the FFI binding uses.

[Yichun Zhang (agentzh)]

Hello!

On Wed, Mar 16, 2016 at 2:54 PM, Aapo Talvensaari wrote:
> I have actually seen that trick. But I have been thinking that it is too
> clever and can cause other issues, like updating package through package
> manager, and trying to figure out what library the FFI binding actually
> uses. One in package.cpath or one in system path. Maybe it is not.

Well, it's for C components specific to the Lua library, not something
much more general like libiconv.

Installing such DSO into the system is too invasive. (Different
applications on the same system may use different such DSO files with
the same name.)

> It's
> really uncommon trick that I rarely see on other LuaJIT FFI bindings.

Yeah, we're trying to figure out a good enough way. Installing such
DSO into the system is far from satisfactory from a sysadmin's
perspective.

> And
> also, I think that if that trick is in place, it should try to find the lib
> with and without "lib" prefix.

Well, as I've said, such DSOs are part of the Lua libraries
themselves. They have total control over the DSO library file names.

> Just like LuaJIT does on system path. Also it
> seems that the trick implemented in lua-resty-json seems to follow *nix
> convention only, and it doesn't try to load .dylib or .dll files (are there
> others – and that could be a source of confusion as well?).

This is why OpenResty always uses .so for DSO components of Lua C
libraries even on Mac OS X (where .dylib is normally used) and
Microsoft Windows (where .dll is normally used). This way, nginx.conf
can be more portable for their lua_package_cpath configuration values.

> I'm not sure it
> is worth it, and if it really is, then the right place to write it is
> directly in LuaJIT. Maybe OpenResty's fork of LuaJIT can search also on
> package.cpath, so that the trick is standard in OpenResty.

Nope. OpenResty's LuaJIT is not really a fork. We do not add new
features or change standard behaviors. At least not yet :)

But I do hope that the standard LuaJIT core can do that by default :)

> Now people may
> follow incomplete (in my opinion) lua-resty-json trick and that may cause
> even more confusion that it might solve.
>

This trick is just a work-around to solve path search problems. As
I've said, in many production environments, installing into the system
is no option.

> I'm not against it totally, but I'm not yet convinced of it either. It feels
> a bit hacky in its current form.

Yeah, sure, it's a bit hacky. You're welcome to provide much better solutions :)

Best regards,
-agentzh

[Aapo Talvensaari]

On Thursday, 17 March 2016 02:08:55 UTC+2, agentzh wrote:

Hello!

On Wed, Mar 16, 2016 at 2:54 PM, Aapo Talvensaari wrote:
> I have actually seen that trick. But I have been thinking that it is too
> clever and can cause other issues, like updating package through package
> manager, and trying to figure out what library the FFI binding actually
> uses. One in package.cpath or one in system path. Maybe it is not.

Well, it's for C components specific to the Lua library, not something
much more general like libiconv.

Yes, in that case it makes a sense. Placing something like libnettle, which is official general purpose GNU library in package.cpath feels a bit wrong. But I agree, that if you build library for specifically Lua, it makes sense to use such a trick.