[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua distros again
- From: Dibyendu Majumdar <mobile@...>
- Date: Thu, 8 Feb 2018 20:23:34 +0000
On 7 February 2018 at 23:30, Sean Conner <firstname.lastname@example.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:
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
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
In order for Ravi to find the libraries on Mac OSX I need to set something like:
Now in my CMake build by default the library gets created as:
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.