lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I used the depends.exe tool from the Platform SDK and got a much more
specific error:

'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...

steve d.

On Wed, Jul 16, 2008 at 2:23 PM, Ignacio Burgueño
<> wrote:
> 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