nm hello.so on Mac OS X should give you output something like this:

00000d30 t __ZL23compute_average_and_sumP9lua_State
00000cc0 t __ZL5worldP9lua_State
         U _luaL_register
         U _lua_error
         U _lua_gettop
         U _lua_isnumber
         U _lua_isstring
         U _lua_pushnumber
         U _lua_pushstring
         U _lua_tonumber
00000c50 T _luaopen_hello
         U dyld_stub_binder

What does it mean?  The ‘T’ beside _luaopen_hello is very important.  That indicates this is publicly defined symbol for the entry point for the shared object.  When we say:

require 'hello'

It means that Lua is looking for a function with C linkage named _luaopen_hello.  If we were to do:

require 'foo'

Then Lua would look for a shared object called foo.so (or foo.dll under windows) with an entry point “_luaopen_foo”.

If we look at these symbols:

00000d30 t __ZL23compute_average_and_sumP9lua_State
00000cc0 t __ZL5worldP9lua_State

These are the two Lua C functions we have defined in the file.  The small ‘t’ indicated they private.  They have the funny ‘name mangling’ going on since they being exported with ‘C++ linkage’.  Since C++ supports having functions with the same name but different arguments – i.e. function overloading every C++ compiler has it’s own unique non compatible way of mangling exported C functions. For our purposes it doesn’t matter since the mechanics of how the hello.so extension library works is that Lua is doing the work of passing the address of these two functions back to the Lua instance running inside of Iguana.

The rest of the symbols that have a ‘U’ beside them are undefined.  This means that when the hello.so is loaded that the operating system will attempt to resolve these function symbols from the process that loads them.  In this case the process is Iguana which has these functions defined as part of the Lua instance that it is running.