I have program using gtkmm, gtkglextmm and exiv2.
I want to include these libraries with the executable, because the app will not work if user doesn't has them on his/her system. On Windows .dll files solved the matter (I put them in the same directory as output file).
How to attached similar libraries on Linux? Is there any tool helping with that? I cannot force user to install dependencies.
Standard practice on Linux is not to redistribute your dependencies. Doing so just creates large amounts of duplication. You should instead specify the dependencies in your installation package and let the package manager resolve them.
Better yet, use the package system of the distribution[s] you want to target, e.g. .deb packaging on Debian/Ubuntu/Mint (with aptitude or apt-get, themselves using dpkg), Yum/Rpm on Redhat/Fedora, etc etc.
DLL-s are called shared libraries (files named *.so) on Linux (in ELF format, use objdump, nm ... to explore them, and gcc -fPIC -shared to build them). They can be programmatically loaded with dlopen & dlsym. Beware that there are important differences between windows DLL-s & Linux *.so (dynamic linking don't have the same meaning on Windows & Linux)
You can write simple sh script to start your program:
#!/bin/sh
LD_LIBRARY_PATH=/path/to/intall/directory
path/to/your/exe
and put so libraries to /path/to/intall/directory
Related
I have an issue where I'm developing on one system where Boost is installed on:
/usr/include
/usr/lib
On a system I will deploy this on, the libboost libraries are at:
/nfs/mount/boost
/nfs/mount/lib
And I can't go about changing every system I deploy on to install libboost in the same place.
Is there a way to either:
include libboost as part of the binary executable such that loading from the system lib paths is not needed.
make the executable search for different directories when trying to load to libboost?
I'm using g++ 8
Sounds like you need a more sophisticated build environment.
I'm not sure what you mean here:
include libboost as part of the binary executable such that linking is not needed
Linking is not something you can skip. If you are trying to avoid distributing .dll/.so files with your executable, you need to avoid using the portions of the boost library that require compilation of the boost binaries (i.e. those not listed here https://www.boost.org/doc/libs/1_62_0/more/getting_started/windows.html#header-only-libraries).
Of course, that is not often the case. So...
make the executable search for different directories when trying to link to libboost?
This will never work reliably as you scale and is a nightmare in the CI world. This is where package managers such as conan (https://conan.io/) come to save the day. Delegating the package management to a third-party is the most reliable way of getting your code to build across multiple environments/platforms.
Also, building your executable and distributing it are separate operations. Any dynamically linked libraries will need to be discoverable on the system path at runtime.
I'm first time using Linux and I have to use QT to make some c++ programs.
In windows, the easiest way to package the dependency libraries is to put all *.dll file with my *.exe into a folder and throw it to somebody.
What's the counterpart in linux to do the similar things. I didn't find any *.exe and *.dll in linux.
So the canonical reference to this problem is this: http://doc.qt.io/qt-5/linux-deployment.html
With Linux you're best off sticking to the shared library approach, which you can either package yourself in a .tar for distribution, and you can find the dependencies by using readelf -d and then find / | grep '<dep-name>'. The other option is to distribute your binary as an rpm/deb/other which lists the dependencies it needs to run and will install them through the package manager.
I have build an application in C++ which is linked with 3rd party shared libraries such as opencv. Now I would require to package this application and redistribute as tar files to users, with out having them to install and compile the 3rd party dependencies. Compiling libraries such as opencv in linux/Ubuntu is such a painful process.
Now I will want to find exactly what all specific modules of a library is linked to executable and include them in the distribution tar. I dont want to include the whole library as the size will of the tar will blow up.
Will it be sufficient enough just to include libraries detected by the ldd command? Any guidance or tip-off/starting point would be helpful
By its definition "ldd - print shared object dependencies". Besides, I personally confirm that it works as I always use it in professional projects.
Also you can check the same question and answers here.
https://unix.stackexchange.com/questions/120015/how-to-find-out-the-dynamic-libraries-executables-loads-when-run
The ldd command can be used to show what libraries an executable (or library) is linked to.
I tip that it works for me (after adding all dependencies with ldd) is to install a fresh linux in virtualBox and try the distribution tar as I'd be the final user. That way you can check that everything is ok.
I'm wondering how to "package" a C++ project for release. It uses various libraries, and I don't want a user to have to go through the same setup I did, with putting the right files in the right place and such. I had difficulty researching this, because I'm not sure the technical term for this issue. If I'm using command line compiling on Linux, is there an easy way to do this?
Your approach to this will differ on Windows and Linux because each OS handles this a different way. I'm more familiar with Linux so I'll restrict my answer to just the Linux side of things.
When you link your executable with a library using -l flag the linker defaults to looking in the normal system library directories so there are four approaches here.
Require the user to properly install the libraries themselves. However, it sounds like you don't want to do that.
Have the user add the library location to LD_LIBRARY_PATH variable.
Your third option is force the linker to look in a certain path for the libraries using the -rpath flag. For example, to have the application look in its working directory for a shared library you can compile with: g++ -rpath ./ -l SomeLib -o MyApp myapp.cpp
One other option is to static link your code with their library that way you only have to distribute one executable. If a static library exists you can use g++ -static -l SomeLib -o MyApp myapp.cpp to tell gcc to link statically.
On windows I would recommand wix http://wix.sourceforge.net/ to create the .msi installer
I would like to point out, the lookup path for .dlls I recommand putting all .dll in the same folder as your .exe since this has the highest priority
However, the vc crt (the c/c++ runtime library) should be installed using the redistributional package from microsoft -> updates automatically http://www.microsoft.com/de-de/download/details.aspx?id=5555
Wix can include the redistributional package into the same .msi therefore you have only to deploy a single installer file.
You mean an installer?
On Windows the program that you run to install a new app which outs everything in the correct directory, creates the start menu and lets you un-install it?
There is an installer builder in Visual Studio (might not be in the free express version) which makes .msi installer files. It's fairly easy to use for simple tasks but becomes complicated to do anything more.
Alternatively, to create traditional setup.exe type installs I use the excellent free Innosetup
On linux you would generally create a package using whatever format your distribution uses (.deb / .rpm ). There are lots of instructions on the specifics of each one and the tools to do so will probably already be installed in your Linux system
In the project I am working on, we provide the possibility to dynamically load additional features. For that we use dlopen.
To find this libraries we have something we call module path. There we have a default path, where the shared libraries are (a lot of them are shipped).
At the moment we have two default paths: we first look in the build directory for the shared library and afterwards in the install directory. This is because it should also be possible to run the application without installing it (so in that case it needs to look first in the build directory).
Now the problem ist, if a user builds the application from source and installs it with make install, the libraries in her build directory are loaded by default. This will result in a crash. So it only works if the user afterwards removes or renames the build directory.
No the question: is there a trick (either by C++ or by the build system) to know whether the application is installed or not. The problem is, that the functionality is implemented in a shared library and the implemented way to search for modules has to work also for other applications that link against our library (so we can not rely on the path of the executable). We use CMake as a build system.
To make the situation even harder, the solution has to work on Windows, Linux and Mac OS X.
EDIT:
I further investigated and the problem is more complicated. This is the situation:
There is a small executable a
Furthermore there is a "main" library main.so
then there is a dynamically loaded library lib.so
lib.so links against main.so
The problem is, that lib.so has the absolute path to main.so in the build directory in its rpath. Thanks to the tip of #MSalters I now was able to make a hack to make sure to load the correct version of lib.so (the one in the install directory) but since it has the build path in the rpath it loads the wrong main.so (so in fact there are two copies of main.so in the memory - this messes things up).
Is there a way to remove this reference to the build path from the library? I tried all options of cmake related to rpath without success
Can't you check where the executable itself is? If it's in the build directories, use build libraries -- if it's in the install, use install?
getcwd() has equivalents on all of those platforms, but it might not be what you want -- it depends on how you run the executable.
To get the process's location is system specific, I think, but it shouldn't be too hard to wrap that.
The installed version should not have the build directory in the rpath.
You might want to do the linking twice (once for the build version and once for the installed version). Usually, on *nix systems, the installed binary has some static path where it tries to find plugins. You might define some environment variable (or command-line argument) to overload it for the build execution (and use a wrapper script to set it in the build environment).
Check how it is solved by some projects (Firefox for example).
I don't know much about windows system but I think the standard way of doing this is to search plugins in the same directory as the executable.