I am currently trying to link a library using MinGW with the following command:
g++ main.cpp -l"C:\Users\Trent\Desktop\glfw3"
This command does not work, however the following does:
g++ main.cpp -lglfw3
Because of this, I think the compiler is probably searching for glfw3.dll in C:\Users\Trent\Desktop\C:\Users\Trent\Desktop which obviously doesn't exist. Is there a way to tell G++ to search for a library using an absolute path rather than a relative one?
P.S. The main.cpp file contains no code, I am simply just trying to link a DLL before I actually write anything.
For gcc family -l is option to specify library name, it searches names in system folders (defined in environment), you can add folders to lookup list by the -L option, just like VTT commented.
Related
I'm trying to link a game library for my game project in C++. I am using the g++ compiler and Atom Code Editor. Also on a Windows machine.
To link the library it needs to link those things:
Include path
Library path
Additional dependencies
The main.cpp file is at ProjectRoot/src/main.cpp and the library is at ProjectRoot/deps/lib_name
Inside the library there is and include folder, with the .h file for including, and a lib folder, with the .lib file. It's a static linking library.
So far, I've tried the following commands:
g++ -o ExecutableName.exe -I /deps/lib_name/include -L /deps/lib_name/lib src/main.cpp
Well, that didn't work though... It said that there was no such file or directory as library_name.h...
I need to know if I'm doing anything wrong and also how to specify the additional dependencies.
Every thing is correct . You just forgot to link the libraries . Do it as follows -
g++ -o ExecutableName.exe -I /deps/lib_name/include -L /deps/lib_name/lib src/main -l[library name] -l[library name]
I am trying to compile and run a C++ program on a server where I don't have root access. I am having trouble linkingboost_iostreams library.
I can successfully compile my program by pointing to the boost installation directory using the -L flag as:
g++ -I path/to/boost/build/include -o out prog1.cpp prog2.cpp -L path/to/boost/build/lib -lboost_iostreams
However, if I run the program as ./out I get the error error while loading shared libraries: libboost_iostreams.so.1.67.0: cannot open shared object file: No such file or directory since the linker is not able to locate libboost_iostreams.so.1.67.0 (which DOES exist under path/to/boost/build/lib)
Thanks to this answer, I was able to explicitly specify LD_LIBRARY_PATH and run the program as
LD_LIBRARY_PATH="path/to/boost/build/lib" ./out.
Since I am not root, I can't run ldconfig either. I was wondering if there is a way to load dynamic libraries without having to prefix LD_LIBRARY_PATH when you run the program and no root access.
I have figured out a way to solve this using the method explained here https://amir.rachum.com/blog/2016/09/17/shared-libraries/. The solution is to use rpath during compilation.
According to the article The only difference between rpath and
runpath is the order they are searched in. Specifically, their
relation to LD_LIBRARY_PATH - rpath is searched in before
LD_LIBRARY_PATH while runpath is searched in after. The meaning of
this is that rpath cannot be changed dynamically with environment
variables while runpath can.
In short once you compile with -rpath path/to/boost/build/lib, the directory containing the library libboost_iostreams.so.1.67.0 is searched at runtime without having to prefix LD_LIBRARY_PATH="path/to/boost/build/lib" ./out.
After compiling with
g++ -I path/to/boost/build/include -o out prog1.cpp prog2.cpp -L path/to/boost/build/lib -lboost_iostreams -rpath path/to/boost/build/lib
I was able to run ./out without any issues.
EDIT 1
As pointed by Nikos in the comments, alternatively you can set your LD_LIBRARY_PATH by export LD_LIBRARY_PATH=path/to/boost/build/lib. Add this line to .~/.bashrc file so that it is not lost when you log out.
I have the following problem:
I have two separate c++ projects, and want to use certain functions from one of them in the other. I am compiling using g++, on Linux.
I decided to do this by creating a shared library out of the project from which to use the functions. I added -fPIC to the compiler flags in the Makefile and then created a shared library like this:
g++ -shared -Wl,-soname,libmyproject.so.1 -o libmyproject.so a.o b.o c.o -lc
Then I simply copied the .so file and the header files into the (parent) directory of the new project and added the following to its Makefile:
To LIBS:
-L/../external_proj/libmyproject.so
To CXXFLAGS:
-I/../external_proj
Then I #include the appropriate header file in the destination project code and try to call certain functions from the original project. However, when I compile the destination project I get an error "undefined reference" for the imported function.
My question is then: is there something I'm missing in this setup? Is there perhaps something that needs to be added to the headers in the original project in order to export the functions I want to use?
I should note this is the first time I have attempted to use a shared library in this way. Thanks.
The -L option only specifies the directory where the linker will search for libraries to link with. Then you will need to use the -l option to specify the base name of the shared library (without the "lib" prefix and the ".so" suffix).
But even that will unlikely to be enough. The runtime loader needs to find the shared library, when you attempt to try to execute it. -L and -l will be sufficient to successfully link, but the runtime loader only searches /usr/lib(64)?, and a few other places by default. It does NOT search the current directory, and the ELF binary only records the names of the shared libraries that must be loaded, and not their full pathnames. You have to explicitly record any extra directories to search for any shared libraries, which is the -rpath option.
To finish the job you will also need to pass -rpath to the linker, but g++ does not support this option directory, you will have to use -W to do that.
The full set of options you will likely need are:
-L/../external_proj -lmyproject -Wl,-rpath -Wl,`cd ../external_proj && pwd`
See gcc documentation for more information on the -W option.
Absolute pathnames should be used with -rpath, hence the need to obtain the full pathname to the directory where the shared library is.
The -L flag is to add a path to search libraries in. The -l (lower-case L) is for linking with a library in the search path.
Or you can skip the flags and link with the library directly, almost like you do now (but without the -L option).
If you use the -l option, then remember that for a file libname.so you use only name as the library name. As in -lname. The linker will search for the correct files with the added prefix and suffix.
And lastly an important note about the paths used when linking: If you use -L and -l to link with a shared library, it's only the linker which will find the library. The OS runtime-loader will not be able to see the path used and will not find the library, if it's in a non-standard location. For that you must also set the runtime-path using the special linker option -rpath.
Unfortunately the GCC frontend program g++ doesn't recognize that option, you have to use -Wl to tell g++ to pass on an option to the actual linker. As in -Wl,-rpath,/path/to/libraries.
To summarize, here are the different variants you can use:
Link directly with the library: g++ your_source.cpp ../external_proj/libmyproject.so
Use the -L and -l options: g++ your_source.cpp -L../external_proj -lmyproject
To set the runtime linker path: g++ your_source.cpp -L../external_proj -lmyproject -Wl,-rpath,../external_proj
When compile with g++ -lboost_system code.cpp -o a.out, the linker will try to find the library file (libboost_system.so). What if there are more than one such file existing in different directory, how can I know which one is been chosen?
PS: I try to compile a project, it needs a high version of libboost than the one been installed. I compile libbost_1_55_0 and install it to /usr/local/, however, when I try to compile the project, it still report errors about libboost, it seems that the old version is been used rather than the new version. I want to make out which version of boost is been used.
From the gcc man page:
-Ldir
Add directory dir to the list of directories to be searched for -l.
I have a shared library that I wish to link an executable against using GCC. The shared library has a nonstandard name not of the form libNAME.so, so I can not use the usual -l option. (It happens to also be a Python extension, and so has no 'lib' prefix.)
I am able to pass the path to the library file directly to the link command line, but this causes the library path to be hardcoded into the executable.
For example:
g++ -o build/bin/myapp build/bin/_mylib.so
Is there a way to link to this library without causing the path to be hardcoded into the executable?
There is the ":" prefix that allows you to give different names to your libraries.
If you use
g++ -o build/bin/myapp -l:_mylib.so other_source_files
should search your path for the _mylib.so.
If you can copy the shared library to the working directory when g++ is invoked then this should work:
g++ -o build/bin/myapp _mylib.so other_source_files
If you are on Unix or Linux I think you can create a symbolic link to the library in the directory you want the library.
For example:
ln -s build/bin/_mylib.so build/bin/lib_mylib.so
You could then use -l_mylib
http://en.wikipedia.org/wiki/Symbolic_link