[SOLVED] Building a self-contained unix executable (CMake)?

[mangoesfruit]

Hal

[CuteAlien]

You can link Irrlicht statically. According to documentation you have to set the _IRR_STATIC_LIB_ define when compiling Irrlicht and also in your application. Depending on which build-system you use Irrlicht has options for "static" building. For example it's the default for the Makefile, thought checking it right now... it does not set _IRR_STATIC_LIB_ on Linux there which is a bit confusing (it does when compilng with code::blocks). I guess it doesn't really make a difference on Linux and the only difference there is that it does not pass the -shared flag to the linker.

Btw, you can check all dependencies of your binary with the ldd command (you probably know already - otherwise - just run it on the binary).

It's also possible to have dynamic libraries in a relative path, though not used so much. To do that you pass an rpath to the linker with a relative directory in which the shared libs can be found.

[mangoesfruit]

Tha

[CuteAlien]

Yeah, .so or .a does not depend on the define. That's a linker option.

Linux distrubutors tend to only package shared libraries.
To have a static version you have to compile Irrlicht yourself (I forgot about that earlier as I always compile it and haven't used a distributor version in a while).
So download Irrlicht (preferably with svn, thought the .zip file also works). I usually put the library somewhere beside my projects or into some sub-folder of it (or often I use soft-links to the real place which makes it easier to swap it with some other version). Compile Irrlicht, the default is generatinbg a static library. So usually you just have to run make in the source/Irrlicht folder and it will create the library (if you want also the examples to compile, which can be nice for testing, then run buildAllExamples.sh in the examples folder instead - this will build the library + all examples).

Then in your CMake file set the include and linker directories both to the place you put your library. The Irrlicht.a will be in lib/Linux (so your linker path has to point to that and the include path to the include folder).

[mangoesfruit]

Tha

[CuteAlien]

Ah right, that fix wasn't backported to 1.8. It's not needed on Linux as we don't even use that function there so far. And it got removed on newer glibc versions.
2 solutions:
a) check-out new 1.8 version from svn, I've just backported the fix there (in revision 6236).
b) Change code manually in COSOperator.cpp like that:

Code: Select all

#ifdef _IRR_OSX_PLATFORM_
#include <sys/sysctl.h>
#endif

[mangoesfruit]

Ma

[CuteAlien]

You can't use paths in the name when linking libraries. You always just link to the library name itself like: -lIrrlicht
So also leave out the 'lib' and the .a parts of the name. But ensure later if it really found the static one, as it might prefer a .so lib it finds, in which case you have to force it to use the .a with a -static flag (checking if it works can either be seen by output of the command-line where it usually tells which libs it links or later on by calling ldd on the binary where static libs no longer show up).
The path then has to be set as linker-path. On gcc/g++ you set that with -LPath (so -Lirrlicht-code/lib/Linux in your case).
Not sure about CMake as it set the include paths with their own macro (include_directories), then it maybe has a similar macro for linker directories.

And don't worry about asking, it's no problem :-)

[mangoesfruit]

O

[CuteAlien]

You can delete/rename the .so file. Or de-install the Irrlicht-dev package, you don't need it anymore if you compile from source.

[mangoesfruit]

I un

[CuteAlien]

That means you haven't set the linker path to the place where the Irrlicht.a file is. Or it's set wrong.
I just check CMake documentation and you have to set link_directories.

[mangoesfruit]

o

[mangoesfruit]

I ha

[CuteAlien]

Yeah, you can compile. 'ld' is the linker - so you now have a linker error.
You can compile as soon as your include_directories are set correct (aka it finds the header files).
You probably still miss the mentioned link_directories. So it does not find the Irrlicht.a file.

Adding correct link_directories will fix it, but in case you want a bit longer explanation of what's going on:

The job of the compiler is to generate object files which contain the assembler code for your .cpp file. For functions which are not in your .cpp file you can still reference to them if you give the compiler enough information so it knows the function name exists and the byte-size of all it's parameters. That's the class/function declarations. Which tend to be put into headers. The pre-processor later simply copy-pastes your header files into the cpp file at the position where your #include was. And as long as the compiler has the info those functions exist somewhere else it will trust you and put some place holder in the object files for them.

The job of the linker is to put all the assembler code which is distributed over object files/libraries you need in your application together. And then it replaces the function place holders with their real addresses. Which is why it complains if it has some reference to a function but you don't give it the object files (or library) which contains the real code (the function definition).
At least when static linking. If you do dynamic linking (shared libraries) then it still uses some kind of place holders and the real addresses are only resolved when your application starts and loads the shared library.