lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

The way to do this is for someone (not me) to write a library packaging API
that can be stubbed out in such a way that by default on an ISO C platform
it can still link directly with application, but can accommodate linking to
a shared library with a simple replacement of the lualibraryISOC.c file with
lualibraryWin32.c file in the build (and the appropriate project setting of

Modules written in this API still must presents their interface to Lua as
they would if it were dynamically linked, so the Lua side API has to be
defined as well (which I believe is something there are suggestions for).

In such a system extension writers need to code to the Lua shared library
abstraction and people writing in Lua need to code as if they are loading
libraries (obviously a auto-loader could be built, but runtime loading is
also needed).

Some of these libraries will have system dependencies; such a system just
makes Lua have a uniform dynamic linking API and people who want to build
monolithic application can use the same library source or none at all in
which case the default ISO C linking API will always fail to load modules
than have not been statically linked.


> From: "Peter Loveday" <>
> Reply-To:
> Date: Thu, 6 Jun 2002 09:21:15 -0400
> To: Multiple recipients of list <>
> Subject: Re: Re[2]: My wish list :)    [RE: How can we make lua better?]
>>>>> 1) Extensions to stand-alone interpreter (without recompilation)
>>>> Vote: No, Library specific
>>> Library specify?  How tedious.
>>> This might be okay for internal development, but I need to offer a
>>> means for my end users to load third party libraries.  This would
>>> be a documentation and tech support nightmare.
>> So implement a loadlibrary function... It's been done.
>> No reason to create 'Extensions to stand-alone interpreter'
> I could easily write a loadlibrary, but this misses the point entirely.
> I don't want to have to take everyone else's modules and produce versions
> that are compatible with 'my' loadlibrary, then have someone else do the
> same thing, and another...
> We'll wind up with a nightmare of incompatible modules, some of which
> work together and others don't due to not being available for X's
> version of Lua.
> And for the end users, consider the confusion this will generate.
> This is why its important to have a standard; not because its hard to
> implement, but because we don't want a dozen different implementations
> used by different libraries that are all incompatible.
> - Peter