Hello forum!

I'm trying to build my application on Linux. However I fail on Lua.

KDevelop uses my CMakeLists.txt, sadly I cannot get it to work. I get "undefined reference" with all kinds of Lua methods which my Lua binding tries to call.

The Lua binding is header-only and works just perfect.

On a Windows machine, I know what I need to link to. Sadly, using CMake and Unix is quite a new experience for me, so I have no idea on what to link in the list file.

Could someone help me out? Maybe even tell me the commands I need to include?

The commands I use for Lua:

include_directories (lib/Linux/Lua)
include_directories (lib/Linux/Lua/src)

target_link_libraries(program "${CMAKE_SOURCE_DIR}/lib/Linux/Lua/src")

Do I have to explicitly link the Lua-lib-file? But what are the lib files on Unix? I could not find anything namend *.lib.

Not much idea about CMake, but I can give some info on Linux.

Do I have to explicitly link the Lua-lib-file? But what are the lib files on Unix? I could not find anything namend *.lib.

Right, not having libraries would be tricky to resolve your references! :)

Most library software comes in 2 packages nowadays, the "use" part, containing the stuff you need to use lua (from an enduser point of view), so eg the Lua interpreter, and the "devel" part, the stuff you need to compile and link with lua. At my Fedora system, that comes as 2 packages

lua-5.3.3-2.fc23.x86_64
lua-devel-5.3.3-2.fc23.x86_64

This is Lua 5.3.3, for Fedora 23, at the x86_64 platform. Other distributions have slightly different names. The "devel" packages typically don't install by default, you have to add them yourself. If you ask the filelist of the devel package, Lua library lives in /lib/lib64 at my system:

$ ls -ld /usr/lib64/*lua*
-rwxr-xr-x. 1 root root 211936 Jul 25 22:15 /usr/lib64/liblua-5.2.so
-rwxr-xr-x. 1 root root 241256 Jul 25 22:15 /usr/lib64/liblua-5.3.so
lrwxrwxrwx. 1 root root     13 Jul 25 22:15 /usr/lib64/liblua.so -> liblua-5.3.so
drwxr-xr-x. 4 root root   4096 Jul 25 22:15 /usr/lib64/lua

Files named "libXYZ.so" are shared object files, these are dynamically linked. There are also static libraries that get merged into the executable, they have a ".a" extension instead of ".so". The /usr/lib64/liblua.so entry is a link to the default (5.3) lua version. /usr/lib64/lua is a directory containing libraries used by the Lua runtime, like lfs or lpeg.

At gcc/g++ command-line level, you specify the directory with -L (upper-case el), and the library to link with -l (lowercase el), eg lua-5.2 is linked with

-L/usr/lib64 -llua-5.2 (library reference does not take the "lib" prefix and the ".so" or ".a" suffix. Perhaps the compiler also understands other forms, eg listing the full path at the command line, but not sure.

Note that the -L above is useless, as /lib/lib64 is in the standard library search path.

LuaJIT only provides one package, as far as I can see.

Once I built in on Linux, I cannot find anything related to the name "liblua xxx".

There is no lib-folder either, everything got smashed into the /src/, which was the same as what happens on Windows.

Cannot test it at the moment, but I would probably have to link libluajit.so (2nd row, last item)?

Works :)

Is shared building advised? I heard Linux has a really neat way of handling these. No "dll" hell?

LuaJIT only provides one package, as far as I can see.

Not sure what that means, a "package" is normally a .deb or a .rpm file or so, that a linux distribution uses to deploy software through package management.

If you think that libluajit.so is the only file produced by luajit, that's wrong, you also need header files to compile anything that uses luajit.

Run "ldd myexecutable" to see where it pulls its dependencies from

There is no lib-folder either, everything got smashed into the /src/, which was the same as what happens on Windows.

Assuming you have built luajit from source, yep, that's possible, every project is free to dump its files where-ever it likes in the project. Right next to the source code has a lot of advantages if you work from a shell (no need to constantly switch directories when building and testing changes).

The final product is created when you do some form of "make install", which mostly does a copy of some generated files to the right spot. You can do system-wide installs, which typically requires super user access, or you can do a user install (Linux is a multi-user system, and you don't want to give all users the right to do system-wide installs :p )

An install typically does make a "lib" directory. For luajit, you'll also get an include directory with the header files.

Is shared building advised?

Depends on what you want to do. Traditionally, Unix systems build everything from source. That yields optimal results for each system. Even today "development tools" is right next to "desktop" in a Linux installer, and you get everything you want.

A second option is to hook into the package management system of the distribution. Make a .rpm or a .deb file for a large distribution like Debian. Supplying your own code in the package, and pulling the other libraries that you need from the central distribution.

If you want to distribute only a program, static linking is probably simpler, as that program runes anywhere.

No "dll" hell?

Fortunately, I have no idea what that means :p

Unix is inherently multi-user, and seperate users and processes are kept separate, sharing is not default (it would be a security risk). Libraries use semantic versioning. You can install whatever in your own space, but it won't affect the system as a whole, only you get both the benefits and the worries :)

As a general rule, you don't do things as super-user. Unlike Windows, there is also no actual need to do it anyway. Sane software allows to be installed anywhere, including in a user home directory.

This works for me. Install your distros lua, and add these to the CMakelists.txt

FIND_PACKAGE(Lua 5.3 REQUIRED)

set(INCLUDE_DIRS ${LUA_INCLUDE_DIR})

add_definitions(-DLUA)

include_directories(${INCLUDE_DIRS})

# put this after add_executable
target_link_libraries(PROJECT_NAME ${LUA_LIBRARY})