I have an OpenGL program. I have all the include directories, and everything.
Directory Structure:
Main.cpp
Lib/
GL/
GLEW/
glm/
I compile the program by running:
g++ main.cpp -lGL -lm -lX11 -lpthread -lXi -lXrandr -ldl -I. -lglfw -Llib/ -o main -lGLEW
The error is on -lGLEW. The program compiles with no errors, but when I run ./main, it gives me this:
Error while loading shared libraries: libGLEW.so.2.2: No such file or directory.
This is confusing, as in my lib/ directory, libGLEW.so.2.2 is present, so is libGLEW.so and libGLEW.a.
Can someone please help me?
When running a dynamic linked executable, the linker must be able to find all the libraries it needs. It always searches
a list of fixed default paths like /lib and /usr/lib
additional paths defined by the environment variable LD_LIBRARY_PATH
any non-standard paths hard-coded in the binary by the -Wl,-rpath g++ option.
These are your options for making this non-standard library known to the runtime linker.
So either use export LD_LIBRARY_PATH=<somepath>/lib when running or use -Wl,-rpath=<somepath>/lib (with comma and without spaces) when building.
Related
So recently I downloaded the Linux Subsystem on Windows 10, with Ubuntu.
I can compile an SDL2 app to Linux with the g++ command but whenever I try doing it with i686-w64-mingw32-g++ this command, I get an error saying main.cpp:5:9: fatal error: SDL2/SDL.h: No such file or directory.
The command I'm using is i686-w64-mingw32-g++ main.cpp -w -lSDL2 -o main.exe.
https://imgur.com/a/uqcGCoJ
Anyone knows how to fix this? :(
[EDIT]
So now I've tried specifying the directory of the necesary files with this command: g++ main.cpp -I/usr/include/SDL -L/usr/lib/x86_64-linux-gnu -w -Wall -Wextra -std=c++17 -lSDL2 -o main
which worked but when I use it with mingw it doesn't i686-w64-mingw32-g++ main.cpp -I/usr/include/SDL -L/usr/lib/x86_64-linux-gnu -w -Wall -Wextra -std=c++17 -lSDL2 -o main
https://imgur.com/a/sF6CpcP
You need to include the path to SDL's include directory on the command line. However, you need to include the path to the downloaded SDL for mingw32, not /usr/include/SDL2. The difference is the headers in /usr/include/SDL2 are for Linux and libs in /usr/lib are also for Linux, but you need to link to the Windows libraries.
What I usually do is download the development libraries for Mingw32 and put them directly into my project directory. Then all you need to do is add -ISDL2-2.0.8/i686-w64-mingw32/include -LSDL2-2.0.8/i686-w64-mingw32/lib to your command line and it will be able to find the headers and libraries it needs. Finally, make sure you copy SDL2-2.0.8/i686-w64-mingw32/bin/SDL2.dll to your executable directory in the Makefile.
Also, remember to link SDLmain as well. It handles creating a WinMain for you and all that, and then calls your main function.
I've been doing a simple c++ program with use of curlpp library. I can build and compile everything just right and I can run it if having MinGW in my PATH. When I delete it and copy all curlpp dlls in the directory, it says (of course):
The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
I believe that the problem is that std libraries are not linked statically, but I tried all possibilities and it seems as they are not linked. I type:
g++ -o myApp.exe main.cpp -std=gnu++11 -L(curl,curlpp,opensll) -I(all includes) -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lcurlpp -lcurl -Wl,--as-needed
with no errors, then I run it and I get error from above. Of course, if I have MinGW in my PATH, then everything works.
I tried to change the order of options in the command without any luck. Putting -static-libgcc -static-libstdc++ as advised elsewhere is not working.
Thanks in advance
Regards
I have installed SDL2. I can link my program with
clang++ -lSDL2 -lv8 main.o test.o -o nano8
However, for distributing reasons, I'd like to give SDL2 away with the binary, and hence i've copied libSDL2-2.0.0.dylib under /myapp/lib/libSDL2-2.0.0.dylib
As for the documentation, #executable_path should allow me to link to that dylib instead of the one in /usr/local/lib, but if I run
clang++ #executable_path/lib/libSDL2-2.0.0.dylib -lv8 main.o test.o -o nano8
I get the error
clang: error: no such file or directory: '#executable_path/lib/libSDL2-2.0.0.dylib'
How to set the search path for a dylib?
This is a pain to get right.
I assume that /myapp can be anywhere in the filesystem, and want to load the library from #executable_path/../lib/libSDL2.dylib?
If so you have to use the Run Path and copy and modify the library during linking (this needs to be done every build):
cp /usr/local/lib/libSDL2.dylib build_dir/lib.
Change the install name of the .dylib using install_name_tool:
install_name_tool -change /usr/local/lib/libSDL2.dylib #rpath/libSDL2.dylib build_dir/lib/libSDL2.dylib
Link against build_dir/lib/libSDL2.dylib and set the rpath during linking:
cd build_dir/bin
clang++ obj_dir/main.o obj_dir/test.o -o nano8 -L ../lib -lv8 -lSDL2 -Xlinker -rpath -Xlinker "#executable_path/../lib"
I have not tested this and there is likely to be errors. Use otool -L to examine the library references in both the binary and the libraries in order to home-in on this issue.
A cleaner way:
Install your binaries into /usr/local/bin and provide any .dylibs to be installed into /usr/local/lib. This is better as /usr/local is the place for user-binaries and you don't need the faff above.
I'm trying to use X86_64-w64-mingw32-g++ (packaged in Archlinux's MingW package) to cross compile some C++ code into an Windows executable, however I'm having trouble getting past some issues.
I'm calling
x86_64-w64-mingw32-g++ -o build_win/asm build_win/asm.o build_win/asm_lib.o build_win/socket_boost.o -I../extra/etc -fopenmp -lrt -std=c++11 -g -lboost_system -lboost_serialization
from a makefile, but I get thrown the errors:
/usr/lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lrt
/usr/lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lboost_system
/usr/lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lboost_serialization
This works fine with native g++, so exactly do I have to change for mingw to compile?
EDIT: I have mingw-w64-boost package installed, which includes boost libraries pre-compiled and ready to be linked. However, it seems the naming convention is a bit different, and -lboost_system for example becomes -llibboost_system-mt (not exactly sure what the -mt suffix entails).
Problem is I can't find the mingw counterpart for -lrt. I've tried with both -lrtm and -lrtutils but in both cases I get:
[...]
undefined reference to `__imp_getsockopt'
Are you sure that -lboost_system and other libraries are present in the same directory as makefile ?
If not then please include -L flag which indicates the location of your library.
For example:
-L /path_openmp -fopenmp -L /path_boost_system/ -lboost_system -L /path_serialization -lboost_serialization
Moreover, you need not include -I and -g flag when creating an executable from .o files. These are needed when you create .o from .cpp files.
There is no rt library on Windows.
You are missing -lws2_32.
$ x86_64-w64-mingw32-nm -A /usr/x86_64-w64-mingw32/lib/*.a 2>/dev/null | grep getsockopt | grep " T "
I'm trying to link to a static library, libcovis.a. Everything looks fine but I still have
undefined reference to `CoViG_PublicDemo::MoInS::reset()'
I checked that the name exists in the library
$nm libcovis.a | grep reset
...
_ZN16CoViG_PublicDemo5MoInS5resetEv
...
I'm using linking arguments -L/path/to/libcovis.a -lcovis
What am I doing wrong ?
Edit:
The error might be something else, if do
gcc main.cpp -I/usr/include/opencv -I/usr/include/cairo -I../../Source -o slam -rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo ../../Source/libcovis.a ../../Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
It works !
But when I'm in KDevelop using cmake, I doesn't work anymore. I use
CMAKE_EXE_LINKER_FLAGS:STRING=-rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo /usr/local/src/CoViS-0.0.0-1/Source/libcovis.a /usr/local/src/CoViS-0.0.0-1/Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
CMAKE_CXX_FLAGS:STRING=-I/usr/local/src/CoViS-0.0.0-1/Source -I/usr/include/opencv -I/usr/include/cairo
The only difference I can see is that the paths are absolute and not relative, but if he couldn't find the libs, he would say it...
There are two different issues there, the first of which is the simplest, you have used the wrong compiler options. The -L option tells the linker to also look in the directory when looking for a library. The -l tells it to link the specific library. To link you would then use:
g++ -o test test.o -L/path/to -lcovis
or
g++ -o test test.o -l/path/to/libcovis.a
To force static linking if the same library is present as a dynamic library in the same directory.
The second potential issue is that the order of static libraries in the linker command line does matter, so that might also be an issue if there is a dependency on different static libs.
g++ -o test tests.o -ldependent -lprovider
The linker will process the libraries in order as they are in the command line, and from each static lib it will only pull those symbols that are required (with as much information as the linker has at that time). In the command line above, the linker will extract from dependent the symbols it needs for test.o, and that might in turn add new undefined symbols to the program (the dependencies of dependent). When it processes provider it will fill in those symbols. If the order was reversed in the command line, the symbols that are required by dependent but not by test.o would not be added to the executable, as the linker does not know that those symbols will be needed when processing provider.
Should the arguments be like -L/path/to/ -lcovis?
Besides, object files should be placed before libs, for example
g++ obj1.o obj2.o -L/path/to/ -lcovis.
If you see the link succeeding in one context but not another, I suspect the problem may be caused by the order in which the link operation is executed as the linker will discard symbols in a library if they're not needed at the point in which the library is referenced.
Here is a link explaining: http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html
I've run into similar situations in the past the linking order was found to be the cause of the problem.