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.
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 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
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
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.
I'm trying setup a subset of boost and get it properly compiled using bjam, however I'm not getting the result I'm looking for. I'm working on windows using boost 1.37.0.
Let's say I want the libraries smart_ptr and filesystem built/installed. I intentionally chose a header only library and one library needing to compile a library. I want them to be built into a directory structure similar to the one I would get if I built a complete boost installation with bjam (i.e not specifying any --with-libraryX) but of course without all the libraries I'm not interested in.
My first approach was to use the --with-filesystem --with-smart_ptr in bjam, however it seemed like it didn't recognize smart_ptr (I tried smartptr and smart-ptr without success). I guess this is because it's a header only library.
When I removed it and only had --with-filesystem it seemed to copy ALL libraries header files to the install path and only build the libraries for filesystem. The library building behavior was the one I hoped for, but I got tons of header files for libraries I'm not interested in installed in my boost directory.
My second approach was to use bcp to copy the relevant projects. This did work out in the sense that I only got the projects I cared about (and their dependencies). However they didn't provide any make files for building the libraries that was copied. This means I would need to setup projects files for all the libraries that are not header only and manually build them.
So my question is basically, is there a way of selectively building boost that only copies the headers for the libraries I'm interested in and only building library files for the non header only libraries I'm interested in (and the boost libraries they are dependent on course)?
There are probably tons of manual/scripting based solutions for this, but if I could get something running only using bjam would be way more useful for me since adding new libraries or upgrading to a new boost version would be very simple.
EDIT:
Added the complete command line for the first approach:
bjam install --prefix=c:\temp\boostsmall
--build-dir=C:\temp\boostsmalltemp --layout=system
--with-filesystem variant=debug link=static threading=multi
runtime-link=static
Changed scoped_ptr to smart_ptr
Solved it.
The bcp solution had make files for the projects, however I needed to copy the tools directory and the root of the boost directory to the place I copied all my libs to get things up running.
Great question! This is an issue I have recently managed to figure out, I think.
I already had the full Boost libraries installed, including the ones requiring separate compilation.
I managed to create a subset of the Boost libraries (regex) for a particular application I was working on using the following steps:
First ensure the bcp executable is installed in the first place. In your Boost root folder, navigate to the tools/bcp folder and run the bjam.exe in here. For me this created the bcp executable in [Boost path]\bin.v2\tools\bcp\msvc-10.0\release\link-static directory:
Then create the folder where you would like the Boost subset to reside. This might already be a folder for a Visual Studio project you are working on.
Run the bcp exectubale you created, making sure to include the libraries you wish to include, as well as the location of the boost root directory and the destination folder. Observe how the required Boost components (eg for regex) have been included in your destination folder.
bcp.exe regex --boost="C:\Program Files\boost_1_55_0\boost_1_55_0" C:\Projects\RegexProject\BoostLite
In your Visual Studio project set the Additional Include Directories and Libraries to point to the 'Boost lite' folder that was created.
One final thing - which I think is described previously - I needed to go to my regular Boost folder setup and copy the required stage/lib folder containing all the lib files needed for the subset version and copy them here, just a few regex-related lib files in my case.
I found that this worked for me. Any feedback from other persons experiences would be appreciated.
A blog posting describing the same thing can be found here.