Re: Lua distros again

[Sean Conner <sean@...>]

It was thus said that the Great Dibyendu Majumdar once stated:
> On 28 January 2018 at 16:40, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> 
> > I have always wanted to (but haven't managed to yet) bundle some high
> > quality libraries with Ravi in a well tested combination with support
> > for Windows, Linux and Mac OSX. Is there a list of the best essential
> > libraries for Lua? I want to bundle a small set of high quality
> > libraries that I will test with Ravi, rather than a huge set of
> > untested libraries of varying quality.
> >
> 
> I wanted to ask your views on couple of points:
> 
> 1. Should I force all libraries to have a require string that is of
> the format 'supplier.module' ? The problem in enforcing this is that
> it makes the distro incompatible with existing code. A better approach
> may be to use the require string that the module provides but prohibit
> any other use of the same module path. This is easy as I have control
> over which libraries go in.

  What is the concern here?  So far, Lua has managed without a conherent
namespace for modules.  If Ravi is meant to run existing Lua code then you
pretty much *can't* enforce a new requirement.

  The stock Lua interpreter provides a mechanism but no real policy.  That
allows experimentation, but it also allows conflicting modules to exist. 
Lua also doesn't care about versions (or version numbers) of modules.  The
ULua distribution [1] does enforce semantic versioning for any modules it
supports, so there are Lua distributions that are opinionated.

> 2. Folks that have experience with modules implemented as shared
> libraries - what are the gotchas? I found two potential issues
> already:
> 
> 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?

> 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.

  Lua uses dlopen() (a POSIX function) to load Lua modules written in C.
Only in the case when the filename of a shared object does *NOT* contain a
'/' does dlopen() check the environment variable LD_LIBRARY_PATH (and only
if the program is not setuid or setgid).  If not found (or LD_LIBRARY_PATH
isn't set) does dlopen() then check system wide locations (under Linux, the
paths in /etc/ld.so.conf).

  The 'lib' prefix is a result of the C toolchain.  When you invoke the C
compiler like:

	cc -o myprog *.o -lfoo

it's the toolchain that adds the 'lib' to 'foo' and looks for 'libfoo.so'
(and if not found, 'libfoo.a').  If you don't specify the '-L' option, then
the system defaults are searched for 'libfoo.*'.  If a '-L' option *is*
given, said directories are searched first.

  Again, the whole 'lib' prefix is added by the C compiler toolchain.

  Also, shared objects can reference other shared objects.  

  What problems (errors, etc.) have you actually encounted with this issue?

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

  -spc

[1]	http://ulua.io/index.html