APR precompiled binaries for windows fail to load.

[greatwolf]

> require 'apr'
error loading module 'apr.core' from file 'G:\LuaJIT-2.0.2\share\apr\core.dll':
   %1 is not a valid Win32 application.

stack traceback:
    [C]: at 0x66dcaac0
    [C]: in function 'require'
    G:\LuaJIT-2.0.2\lua\apr.lua:16: in main chunk
    [C]: in function 'require'
    stdin:1: in main chunk
    [C]: at 0x00402050

I've also tested this not just under LuaJIT-2.0.2 but also Lua-5.1.5 and the interpreter included with wxLua (uses Lua 5.1.4). They all fail with basically the same message.

Is there a solution to this? Do I have to build apr from source? If so, how can I use mingw to build it?

[greatwolf]

Just reporting back incase future visitors run into the same problem. I was able to successfully build lua-apr using mingw gcc4.6.3 with MSYS environment. I had to modify the makefile for gcc somewhat to accommodate for platform differences.

In the end, the compiled core.dll still exhibited the same issue. The real problem was due to TortoiseHg supplying its own APR dependencies. TortoiseHg added itself to my environment PATH variable when I originally installed it. lua-apr ended up trying to use TortoiseHg's supplied APR runtime instead of its own and that caused the issue I was having. Removing TortoiseHg from my environment path corrected the issue.

Looking more at the technical reason, the APR dll runtime supplied by TortoiseHg has the same apache runtime functions but decorated differently. Inspecting its export table shows many of the functions are just plain undecorated functions that look like __cdecl convention.

The apache runtime binaries supplied by lua-apr binary as well as from Apache's site shows those same functions decorated with leading _ underscore + @ ampersand and byte suffix indicating that __stdcall is being used. At any rate, it's unclear to me why TortoiseHg's APR binaries differ from the standard packaging from Apache.