Re: Packaging Lua libraries

[tuomov@... (Tuomo Valkonen)]

On Wed, Mar 31, 2004 at 03:39:07PM -0300, Andre Nathan wrote:
> On Wed, 2004-03-31 at 15:08, Jay Carlson wrote:
> > Obviously .so files need to live in /usr/lib somewhere.  If we think
> > people are going to build their own custom interpreters that don't
> > dynamically load with loadlib, the extensions probably need to start
> > with "lib" so people can link them in when they build their
> > executables.  Version numbering would be good too.
> 
> Yeah, thinking about those who build their custom interpreters, this is
> a good idea (even though some libraries don't have version numbers :)
> 
> How do people do it on other languages, which don't have the "lib"
> prefix? Or they simply don't do it?

The lib prefix should only be required for the -l compiler flag, which
is required to "wisely" choose a version of the library (but too often
that method fails thanks to single a search path and the all-in-one-basket
directory hierarchy). Static .a libraries are simply archives of .o
files and can be linked to by just giving the file name. The same applies
to .so:s, at least with gcc, but you need to be carefull with the paths.

> > The stub .lua loaders are arguably architecture-dependent---you could
> > have different naming conventions or directory paths from platform to
> > platform.

Architechture dependent stubs? That's just brain-damaged. Isn't the
C-side (?) dynamic library loader supposed to handle this? 

Actually, may I suggest simply using GNU libtool+libltdl instead of 
reinventing the wheel? You can specify to it a search path and ask it to
load 'foo' and it will take care of all (or at least most) architecture 
dependencies, including static linking, which can also be forced for 
specific modules at link time with -dlpreopen.

> My initial idea was to do something similar, but is anyone affected by
> this in practice? I mean, does anyone need binary libraries for more
> than one architecture on the same machine?

I guess the main point of having 'share' is that it can be an NFS
mount shared between machines of different architechtures. And, yes,
I expect to find scripts in share, not lib. And when we have an FHS 
standard, I think it should be adhered to, no matter how broken some
popular distributions, languages or the standard may be. (Personally, 
I'd prefer an application directory based hierarchy. With short 
lower-case names, please.)

-- 
Tuomo