Re: Lua distros again

[Sean Conner <sean@...>]

It was thus said that the Great Dibyendu Majumdar once stated:
> On 9 February 2018 at 08:08, Sean Conner <sean@conman.org> wrote:
> > It was thus said that the Great Dibyendu Majumdar once stated:
> >>
> >> 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.
> >
> >   At work we develop on Mac OS-X, and while normally I package everything
> > into a single executable, I do have the ability to install individual
> > modules [1] and they all have a .so extension (just like they do on Linux
> > and Solaris) and Mac OS-X can load them (the Lua modules written in C) just
> > fine.  I did check other, standard shared libraries on the Mac, and yes,
> > they have the .dylib extension [2].  So for Lua modules I don't think it
> > matters all that much what the extension is.
> >
> 
> Sure but that was not the issue I was high lighting. Do you have a
> solution for the problem I described above?

  It could be that I don't have a full grasp of your problem.  I've read
over your message, and as best as I could tell:

	1. You have a Lua module written in C called ravi/ffi, with a
	   filename of "ravi/ffi.dylib".

	2. You have another shared object, NOT a Lua module, called libtest
	    (filename: "ravi/ffi/libtest.dylib") that references functions
	    defined in ravi/ffi

	3. You are having issues loading libtest beacuse of naming issues.
	   Specifically, libtest has a depenency on ffi
	   (ravi/ffi/libtest.dylib has a reference to "ffi.dylib") without
	   any path information so it needs to be searched for.

  Is that the core issue?  And a secondary issue you have is the feeling
that shared libraries need to be prefixed with 'lib'?

  I'm not as familar with Mac OS-X as I am with Linux.  With that, I do load
C-based Lua modules with an extension of ".so" so the name isn't *that* much
of an issue:

[spc]saltmine-2:~/bin>luawhich org.conman.fsys
/usr/local/lib/lua/5.1/org/conman/fsys.so
[spc]saltmine-2:~/bin>file `luawhich org.conman.fsys`
/usr/local/lib/lua/5.1/org/conman/fsys.so: Mach-O 64-bit executable x86_64
[spc]saltmine-2:~/bin>

(saltmine-2 is my work Mac laptop; "luawhich" is a Lua script that displays
the location of Lua modules---code available upon request)

  Now, I'm more used to Linux than Mac OS-X, so to find out what a shared
object's depencies are, I'm used to using ldd:

[spc]lucy:~/bin>ldd `luawhich org.conman.hash`
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x00bfb000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00a35000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x0050b000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00259000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x004e4000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x0081a000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x0052d000)
        libdl.so.2 => /lib/libdl.so.2 (0x00111000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00d30000)
        /lib/ld-linux.so.2 (0x00b76000)

And here, we see that org.conman.hash relies upon libcrypto.so.4 but because
it lacks any path information (and ldd does the search and reports back the
final location), a search is required.  On Mac OS-X ldd doesn't exist, but I
did find that otool does a similar thing:

[spc]saltmine-2:~/bin>otool -L `luawhich org.conman.hash`
/usr/local/lib/lua/5.1/org/conman/hash.so:
        /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

Poking around various programs and shared objects, I found that the full
paths to dependencies are always present, so I'm not sure of the rules for
$DYLD_LIBRARY_PATH are.  You might have some more digging to go through but
if what you have works, I say go for it for now and somebody with more
knowledge might be able to help.

  -spc