I have a C++ project I'm compiling with CMake. One of the dependencies is LevelDB which I have installed using homebrew. In my CMakeLists.txt I have the following line:
target_link_libraries(test /usr/local/Cellar/leveldb/1.23/lib/libleveldb.dylib)
The binary that is generated works fine on my computer but it crashes when I run it on a computer that does not have libleveldb installed, stating that the library could not be found.
Is there any way that I could simply bundle the leveldb .dylib file into the executable itself -- this seems like the most reasonable way of making a binary that is simple for the end user to download and run.
Related
I'm working on a game in SFML. It runs correctly on my computer, but if I send it to another computer then when I try to run it I get errors about not being able to find libraries. I did some research and I found that the reason is because I was using dynamic libraries, and to get the program to work on its own I need the static libraries. But how do I get those? They aren't in my sfml folder. I tried doing more research but I can't find a way to build or download those libraries.
Just go to your sfml Src directory and look for the /bin folder. Copy the following DLLs to your game folder where your exe is located:
DLLs
sfml-graphics.dll
sfml-window.dll
sfml-audio.dll
sfml-network.dll
sfml-system.dll
On Linux, install libsfml-dev on target computer.
I am sure you are using mingw compiler. You can add static arguments and try.
-static-libgcc -static-libstdc++
If this doesn't work try to search the two DLL files in your standard compiler path /bin folder and place them where your exe is located.
I am writing a little project in which I want to call a function from a shared library. For that I want to use libdl.so's dlopen() function.
I have everything set up so that it will work just fine when I build and run it as a 64bit application. However as soon as I am compiling it as a 32bit application and then try to run it, it won't be able to load any library.
dlopen() simply returns null and a call to dlerror() reveals
libtbbmalloc.so.2: cannot open shared object file: No such file or directory
Now I am guessing that I have to somehow install a 32bit version of that library but I can't find it in the package manager and what I have found online isn't too helpful either.
Does someone know that the problem is and/or how I could fic it?
I am building my project via cmake v3.10 and in the CMakeLists.txt I am using this instructions for 32bit:
set_target_properties(clib PROPERTIES COMPILE_FLAGS "-m32" LINK_FLAGS "-m32")
target_link_libraries(clib /usr/lib32/libdl.so)
I have installed the package g++-multilib and my g++ version is 7.3.0.
I am attempting to build my program on Linux Mint 18.3 (6bit).
With the help of #Lorinczy Zsigmond in the comments, I was able to find the problem: I had to install the packages libtbb-dev:i836 and libz-dev:i836 in order for the function loading to work properly.
I'm trying to build wxWidgets library into a custom path on a Fedora 27 operative system.
I achieved the wx-config file path recognition and works with the cmake execution. Also, I load libraries and include dirs based on modified wxWidgets finder cmake file that sets thewx-config custom path successfully.
But cmake does not load my wxWidgets configuration. I mean, wx_gtk2u_jpeg-3.1 builded lib could not be founded (suposed to be /usr/lib/libwx_gtk2u_jpeg-3.1.so). I need jpeg dependency from wxWidgets for my project.
I'm sure that problem is not about cmake files. However, the problem is wxWidgets compilation because cmake can found the other builded dependencies into /usr/lib/
I actually installed the libjpeg-turbo-devel package that includes the libjpeg.h needed for wxWidgets building without success of libwx_gtk2u_jpeg-3.1.so creation.
The weirdest part is that $ wx-config --libs shows the wx_gtk2u_jpeg-3.1 lib to be linked and the hint paths that it should be founded.
wxWidgets commands for building:
$ ./configure --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin --with-zlib=builtin --with-expat=builtin --enable-webviewwebkit=no --prefix=/opt/cpp_dependencies/2018Q1/usr'
$ make -j 4
$ make install
You can check out my cmake files, the cmake output and wxWidgets building output in order to reproducing it: https://gist.github.com/jjalvarezl/b70accae269ef56c56010bedf157c27f
You can see line 1543 of wxWidgets building output file that jpeg library is buildin, and, 1564 of same file, the make install command that installs all libwx_<lib_name>.so libraries into final /usr/lib path. Anyway, no one contains the needed library.
Please show the exact error message, as it's not clear what the actual problem is. What I can say, is that the different built-in versions of 3rd party libraries, such as libjpeg, are always static libraries, even when wxWidgets themselves are shared. I.e. you're never going to have libwx_gtk2u_jpeg-3.1.so, only .a.
I'd also strongly recommend using system versions of the 3rd party libraries under Unix systems. This means that your wxWidgets applications will get security updates from your OS vendor and you don't risk running into any incompatibilities due to using 2 different versions of the same library in your application.
Now I have a opencv project which was build in Linux platform, and of course it can run successfully.
I want to share the execution file of the project to other person(like boss), and other person's computer didn't install opencv
Is it possible to modified the makefile file to let the other person's computer run the project without installing opencv library?
You have to link to static OpenCV libraries. This way they are bundled with your executable, so the target system doesn't have to have shared libraries installed.
I've successfully built my executable with RPATH=$ORIGIN, which mean that I can put the openCV libraries in the same directory as the executable. This means they don't clash with existing openCV installations (or lack thereof)
When you run the executable, you will need the libraries to process the image. So, those libraries must be present for the processing purpose either by providing them in your system or by linking them to your executable itself.
I have a project I'm writing that uses LuaJIT. I'm trying to run my project on a computer I have not run it on in a while. It used to run just fine but now when I try to run it it complains.
I have LuaJIT in my source tree, and it builds just fine. I'm using CMake to generate my make files, and as far as I can tell CMake finds the file libluajit.so, but when I run my program, I get the following error:
../build/game/game: error while loading shared libraries: libluajit-5.1.so.2: cannot open shared object file: No such file or directory
I don't know why it's looking for that version of the library instead of libluajit.so. This is Ubuntu linux for what it's worth. I can add more details if necessary, I can add more details if necessary, I'm not sure what info would be helpful to figure out happening.
Edit:
To build and link the program I have these lines in the file CMakeLists.txt (this is abbreviated a bit to just show the relevant bits)
find_package(LuaJIT REQUIRED)
set(Extern_LIBS luajit)
add_executable(proj ${proj_Sources})
target_link_libraries(proj ${Extern_LIBS})
After I run cmake on my source directory, I run make. Then to run it I just run ./proj
When you built it, the ".so" was actually a symlink to the library. Verisioned filenames and SONAMEs are used so that multiple versions of a library can coexist, preventing problems commonly found on... other operating systems whereby older software is incompatible with the newer library, and newer software is incompatible with the older library.