Re: building, using C module on mac os x fails

[Mike Pall <mikelu-0505@...>]

Hi,

Kim Herzig wrote:
> But when I try to load the library with the following code:
> 
> 	clib = loadlib ("./clib.so", "luaopen_clib")
> 	clib()

If you really want to use loadlib() directly, it is a good idea
to wrap it with assert(). So you get to see the error message
(returned as the second result) on failure. I.e.:

clib = assert(loadlib(...))

> 	lua: main.lua:15: attempt to call global `clib' (a nil value)

This indicates that loadlib() failed and returned nil. But even
though you didn't print the error message, I can guess what's wrong:
OS X requires you to prepend an underscore to all C symbols. I.e.:

clib = assert(loadlib("./clib.so", "_luaopen_clib"))
------------------------------------^

> By the way: The complete code is working under Linux (Debian).

Yes, because loadlib() is pretty system specific. The general
advice with Lua 5.1 is _not_ to use it unless you are doing
low level stuff. Please try converting your Lua code over to
the new module system and use the require() function instead.
You can use compat-5.1 for Lua 5.0 to get the same effect or
just use Lua 5.1 everywhere.

It can be as simple as:

require "clib"

Then you can access the global 'clib' table created by your C module
(provided you used luaL_openlib(L, "clib", clib_funcs, nupvalues) ).
Note that require() (in contrast to loadlib()) both loads the module
file _and_ runs the C module initializer function (or the main chunk
for Lua modules).

Maybe a better alternative is to use:

local clib = require "clib"

This makes clib a local variable and an upvalue for all functions
defined in your Lua code. This is slightly faster and can come in
real handy when you have long hierarchical module names (the name
of the local variable does not have to match the module name).

You can convert your Lua code over to be loadable with require, too.
Just start your Lua module with:

module "myluamodule"

All globals you subsequently define (in particular: global function
definitions) are placed into the 'myluamodule' table and not into
the global table. When this module is require()'ed by another module
you can access them with 'myluamodule.myfunction' (just like the
standard library functions string.sub, io.open, ...).


By default the current directory is in the require search path
for both Lua and C modules. You can install them systemwide by
placing them in:

/usr/local/share/lua/5.1/myluamodule.lua
/usr/local/lib/lua/5.1/mycmodule.so

(This applies to all POSIX systems, i.e. both Linux and OS X.)

The module names passed to the calls to luaL_openlib() and module()
must match the filename. For hierarchical module names ("foo.bar.baz")
replace the dots with slashes (foo/bar/baz.lua or foo/bar/baz.so).
The name of the C module initializer function luaopen_*() must
match the module name, too (replace dots with underscores, e.g.
luaopen_foo_bar_baz() ).

One caveat: since the C API for Lua 5.1 is still in flux, please
remember that you need to recompile all your C modules with
the new header files, when you upgrade to a newer Lua 5.1-work*
release.

Bye,
     Mike