Re: [ANNOUNCE] bare-bones loadlib

["James Hearn" <james.hearn@...>]

> --- James Hearn <james.hearn@byu.edu> wrote:
> > On a small note, the Windows example code compiled out of the box on my
> > cygwin machine. It took a little mucking about in the Makefile. I'm
going to
> > mess with it some more and see what I come up with.
>
> I'm assuming that this whole dynamic loading business assumes that Lua
itself is dynamically
> loaded by the host app.  I don't know about Unix, but under Windows there
would be no other way
> for the host and library to share Lua's code. Unless the host did
something like pass the library
> a table of function pointers, or something like that.  Right?

Let me preface this that I'm not very familiar with the specifics of how
dynamic loading works, and I'm fumbling my way through manuals, compiles,
and trial and error to figure this one out. I'm primarily a Unix coder - I'm
on a Windows box here right now with Visual Studio 6, but I work mostly with
the Cygwin tools and the Sun java compiler. A lot of my confusion comes from
my rudimentary understanding of the interactions between Cygwin and Windows.
Cygwin causes things to "just work" like I expect them to, but its "unix
compatibility layer" is everywhere.

What I got running was a really basic hack of the makefile. I'm pretty sure
it depended heavily on the unix compatibility layer. It definitely required
cygwin1.dll . It compiled lua.c into one program, statically pulling in
liblua and liblualib. Oh yes, I'm using Lua 4.1w4 for all of this.

The next step was to compile 'mylib' into a .dll . For some reason ld was
not happy when I tried to create shared code with it (this is where I
started mucking about). It gave lots of errors relating to undefined
references. After hunting through the manual a bit, a found that

mylib.dll: mylib.o
    dlltool mylib.o -e mylib.exp -l mylib.a -z mylib.def
    gcc -o $@ -shared $? mylib.exp mylib.a mylib.def -L$(LUALIB) -llua

produced a ".dll" that could be loaded dynamically from the test program.
You'll notice that liblua is statically compiled into the ".dll" . I say
".dll" because I'm not entirely convinced that it is a windows .dll proper.
I think it probably depends heavily on the cygwin unix compatibility layer.

Right this minute I'm working on compiling a completely native dynamically
loaded version of Lua and the loadlib test program using the cygwin
toolchain. I'm making progress. Wish me luck!

--James Hearn, who is learning a lot about this in the process...