[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Building extensions with mingw against LuaBinaries
- From: "steve donovan" <steve.j.donovan@...>
- Date: Wed, 16 Jul 2008 14:55:00 +0200
I used the depends.exe tool from the Platform SDK and got a much more
'Cannot find procedure entry point __findfirst in msvcr80.dll'
And true enough, with dumpbin /exports I note that it doesn't export
this, but a set of functions like
That suggested a solution - just #define _findfirst to be
_findfirst32, etc. Since the libmsvcr80.a then complained, I just
linked straight against msvcr80.dll, and voila...
gcc -shared -Id:\stuff\lua\src lfs.c -o lfs.dll lua5.1.dll msvcr80.dll
(note: I had already made -lmsvcr80 to be my default by editing the
mingw gcc spec file)
So it appears to work, through a semi-horrible hack! Although the
rest now seems clear, and I could probably knock a _working_
libmsvcr80.a together from this information...
Thanks for indulging my talking aloud here; this may be useful to others...
On Wed, Jul 16, 2008 at 2:23 PM, Ignacio Burgueño
> steve donovan wrote:
>> Hi guys,
>> I know this has been raised, but I seem to be following a recipe that
>> doesn't work ;)
>> Mingw can link against the msvcrt80.dll runtime shipped with
>> LuaBinaries by using -lmsvcr80. That's fine, and something like lfs
>> compiles. dumpbin tells me that luaopen_lfs is indeed exported, but I
>> get 'the specified procedure could not be found', which seems to
>> indicate that it could not find luaopen_lfs, or had some obscure
>> problem with it.
> When dealing with that kind of problems, the first thing I do is to first
> check the module dependencies, using Dependency Walker:
> If dependencies are ok, then I run the failing test case with Process
> Monitor running on the background:
> With Process Monitor, you'll get a trace of system activity (process and
> threads creation / destruction, disk access, registry access, etc) for all
> processes, so you'll have to filter the output.
> Hope this helps
> Ignacio Burgueño