Lua conflict using external luajit #203
Comments
|
I decided to implement the latter, commited the update in r121800. |
|
I see. Do you have a quick way to replicate this, maybe on a Linux host? If I'm able to experience the issue, I might find some way to directly solve the issue within cmake, rather than the code. Thanks. |
|
I'm afraid the only way to replicate it would be to install both Lua and LuaJIT, yes. |
|
I really have a hard time reproducing the issue. This is what I did, on a Debian box.
/usr/include/lua50/lua.h
I can't seem to replicate your problem. Am I missing something? |
|
At 4), how could cmake pick /usr/include/lua5.1/lua.h? Isn't that header provided by libluajit-5.1-dev? Anyway, the conflict actually happenes with lua 5.2, and that is because (interestingly enough) lua header files are installed directly under /opt/local/include (and cmake has -DCMAKE_INSTALL_PREFIX=/opt/local and -DCMAKE_SYSTEM_PREFIX_PATH=/opt/local;/usr). I don't maintain the lua package, so I don't know if it's ok to install headers under /opt/local/include without subdirs (and that could be the real issue here). |
|
On Wed, Jul 9, 2014 at 10:51 AM, Aljaž Srebrnič notifications@github.com
As I said in 4), "Uninstalled the system's libluajit-5.1-dev..."
Yeah, it sounds like it's wrong to put lua.h under /opt/local/include, it -- Could NOT find Lua51 (missing: LUA_LIBRARIES LUA_INCLUDE_DIR) Anyway, if I manually move /usr/include/lua5.2/lua.h to /usr/include/lua.h, |
|
On 09/lug/2014, at 11:26, Gianluca Borello notifications@github.com wrote:
Ah, yes, sorry.
By embedded you mean the one included in sysdig? Even with -DUSE_BUNDLED_LUAJIT=OFF? |
|
On Wed, Jul 9, 2014 at 11:59 AM, Aljaž Srebrnič notifications@github.com
If I just install lua5.2 on the system and then compile with "cmake ..", it If, instead, I use -DUSE_BUNDLED_LUAJIT=OFF, cmake refuses to run (with the |
|
To reproduce this bug, you should install the latest luajit and lua, move lua header files into /usr/include and build with -DUSE_BUNDLED_LUAJIT=OFF. Cmake will find the system luajit, but due to the fact that In the meantime, I'll start a discussion as to why are lua header files installed directly in include/. |
|
My command line is different than yours. I switched to OSX and, by doing exactly what you said and then The clang line becomes: As you can see, there's no How are you calling cmake? And what's his environment? |
|
The complete cmake invocation is: I'm pretty sure the |
|
I still can't replicate it (I'm on Mavericks): Does: Still no |
|
That's odd. What about if you try to use system zlib and jsoncpp? Since their include files are in |
|
Yes, if you happen to have everything mixed in /opt/local/include, then it can create that issue. Honestly, yours still look like a weird setup and what I'd do is put lua/luajit in separate And I wouldn't do the include |
|
Well, I will for now patch the files to use Grazie, |
Maintainer of sysdig on MacPorts here. We tend to use system libraries when available, so I noticed a bug: when building libsinsp, the compiler somehow picks up standard lua headers, which don't have the #defines for the old lua features (like lua_open, for example) and errors out.
I tried selecting the luajit include dir with -isystem, so it has precedence, but no dice. I finally patched userspace/libsinsp/chisel.cpp by including luajit headers with the full absolute path. Another fix would be using the includes like this:
#include <luajit-2.0/lua.h>. If you decide that, you can even drop the -I directive to specifically include the luajit include directory.The text was updated successfully, but these errors were encountered: