[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Packaging Lua libraries
- From: Doug Currie <e@...>
- Date: Wed, 31 Mar 2004 16:07:06 -0500
Wednesday, March 31, 2004, 23:30:50 +0300, Tuomo Valkonen wrote:
> On Wed, Mar 31, 2004 at 03:39:07PM -0300, Andre Nathan wrote:
>> On Wed, 2004-03-31 at 15:08, Jay Carlson wrote:
>> > [...]
>> 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 same applies to mingw (gcc) and .dll files.
>> > 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?
Off the top of my head, I can think of two things a stub loader needs
to handle: 1. disk, directory, and path name syntax issues across
platforms 2. libraries needed on some platforms and not on others
(e.g., posix emulation, popen emulation); or perhaps different
libraries on each platform to provide the same functions (e.g., fs.lua
on Win32 and posix.lua on linux).
> Actually, may I suggest simply using GNU libtool+libltdl instead of
> reinventing the wheel?
Retch. I guess you don't read the luacheia list? Libtool is an
abomination on many platforms, and a cause of much suffering.