Philipp Janda
Philipp Janda
The `-1` is a (fake) rockspec revision introduced and handled exclusively by luarocks.
+1 I believe there is a similar issue on OSX with the MACOSX_DEPLOYMENT_TARGET ...
Please don't mess with the directory the `lua` executable is installed in (unless LuaRocks installed it there itself). This directory doesn't belong to you, and you have no idea which...
After further thinking: It could be a bad idea to put C modules in a directory that is in PATH anyways, because they might be loaded instead of a normal...
Your `LUA_PATH` is incomplete. You need `C:\Program Files (x86)\LuaRocks\2.2\lua\?.lua`, and you should change `C:\Program Files (x86)\LuaRocks\2.2\lua\luarocks\init.lua` to `C:\Program Files (x86)\LuaRocks\2.2\lua\?\init.lua` (but that's optional since LuaRocks doesn't use an `init.lua` file).
@stefangeorge LuaRocks adds its own module locations to `package.path`/`package.cpath` to keep its own modules separate from the modules installed via LuaRocks. Also by default you get two separate rocks trees...
The problem seems to be that LuaFun has a slightly different interpretation of what iterators are supposed to do than standard Lua. I.e., standard Lua iterators return a meaningful value...
This is a problem in the lua-yajl rockspec. LuaRocks checks the existence of headers and libraries for you and creates variables with the corresponding paths, but the rockspec author is...
This ``` (?luaopen_socket_core@@YAHPEAUlua_State@@@Z) ``` looks like the compiler/linker is expecting a name-mangled (i.e. C++) symbol. There's probably a `extern "C" { ... }` missing around the LuaSocket include (or a...