Re: Lua distros again

[Dibyendu Majumdar <mobile@...>]

On 7 February 2018 at 23:30, Sean Conner <sean@conman.org> wrote:
>> a) in some cases the shared library needs to be on OS specific
>> environment PATH (or library PATH), and
>
>   Have you actually encountered this problem?  And if so, which Lua module
> was it?

Yes of course as soon as I started applying this to the first
component in the proposed distro - luaffifb. I modified the library so
that it would support:

require 'ravi.ffi'

This library comes with another shared library used for testing - this
is referenced from test.lua as:

dlls.__cdecl = ffi.load(package.searchpath('ravi.ffi.libtest', package.cpath))

This immediately fails as 'libtest' has a dependency on 'ffi' shared
library but cannot find it. So one has to set following in the
environment:

export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$HOME/lib/ravi

While this is maybe not a good example as 'libtest' is not a Lua
module per se - it immediately confirmed to me the theoretical
analysis that there is a potential problem.

>
>> b) the path resolution doesn't seem to like it if the build adds a
>> 'lib' prefix to the library (as it does on Mac OSX).
>
>   It sounds like you are still unclear on how dynamic linking works on Unix.

My knowledge is not perfect of course but I also did not explain the
problem fully.

In order for Ravi to find the libraries on Mac OSX I need to set something like:

export LUA_CPATH="$RAVI_HOME/lib/?.dylib;$RAVI_HOME/lib/lib?.dylib"

Now in my CMake build by default the library gets created as:

$HOME/ravi/lib/ravi/libffi.dylib

It appears that Lua searches for:

$HOME/ravi/lib/ravi/ffi.dylib as it substitutes 'ravi/ffi' in place of
'?'. So it cannot handle the 'lib' prefix.

I have amended the CMake script to omit the 'lib' prefix and now it
works fine, but this is not standard naming on Mac OSX I think.

>   Have you tried writing a Lua module in C?  Even a simple one?  That might
> answer most of your questions.
>

Of course - since my first interest in Lua. But I never used the
dotted require statement to access shared libraries before as I was
unaware of this - all my attempts were based on shared libraries being
'top-level' which worked fine.


Regards
Dibyendu