Question on compiling modules

["Pimmel, Keith" <Keith.Pimmel@...>]

I am using cygwin, gcc 3.4.4. I've built Lua 5.1 to run under cygwin, so
I have the following
/usr/local/lib/liblua.a
And also the directory /usr/local/lib/lua/5.1 where my module shared
objects go.

I compiled and linked the luafilesystem module, and it works as expected
when I use the "require'lfs'" command. One modification is that I needed
to add liblua.a as part of my objects to get compiled in, something that
seems to go strongly against the advice that Mike Pall and others have
stated in the list and on the wiki
(http://lua-users.org/wiki/BuildingModules).

When I try and compile another module (lhf's lpack module found at
http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/lpack.tar.gz), I run into the
same buzzsaw; if I don't include the liblua.a, I get errors similar to
the following excerpt:
lpack.o:lpack.c:(.text+0x42): undefined reference to `_luaL_argerror'
lpack.o:lpack.c:(.text+0xcf): undefined reference to
`_luaL_checklstring'
lpack.o:lpack.c:(.text+0xec): undefined reference to
`_luaL_checklstring'
etc...

I understand the sentiment that you don't want to have essentially
duplicated parts of the core in each module that is created. How do I
avoid this? Do I need to create a shared object of the core as well, and
have the modules link against this? If this is the case, I admit some
ignorance in the process; I can create shared objects, but to use them,
would it just be something akin to 

$ gcc -o foo.so -shared -llua foo.o

provided that liblua.so exists somewhere in my library path?

I guess the follow-up question is there any reason to believe that this
would cause issue then: lua interpreter created with static library
using dynamically-loaded modules created with dynamic version of the
same library? That doesn't feel right to me, but I profess a great deal
of ignorance when looking at the build process at this level.

yrs,
Keith
--
Keith Pimmel     ~~~~     Dynetics, Inc.     ~~~~     256.964.4717