I would like to create a dynamic library for c++ program on linux.
In c++ program/system I`m using libconfig++ library, libpqxx library, some boost and c++11.
My steps:
1)
g++ -Wall -I/usr/local/include/ -std=c++0x -lconfig++ -Wall -lpqxx -lpq -fPIC -c ../SourceFiles/DBHandler.cpp ../SourceFiles/ParamServer.cpp ../SourceFiles/Functions.cpp
2)
g++ -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0 *.o
3)
ln -sf libctest.so.1.0 libctest.so.1
4)
ln -sf libctest.so.1.0 libctest.so
5) compile
g++ -Wall -I/path/to/include-files -L/path/to/libraries program.cpp -I/usr/local/include/ -std=c++0x -lconfig++ -lpqxx -lpq -lctest -o prog
After execute above command :
/usr/bin/ld: cannot find -lctest
collect2: ld returned 1 exit status
What am I doing wrong?
Here is the reference:
enter link description here
In step 5, you forgot -L. to look for libraries in the current directory.
By default, only a [long] list of system directories is used when searching for libraries.
You will also need to add . to the LD_LIBRARY_PATH environment variable before executing your program, so that the current directory is searched at runtime, too. Running ldconfig will avoid this, but if you are only testing your library and do not want to persistently affect your system, I would stick to the LD_LIBRARY_PATH approach.
An alternative is to "install" your library into one of those directories, such as /usr/local/lib (or your equivalent). You should use ldconfig after doing this, so that the dynamic library cache and all your symlinks are set up for you. This is the canonical approach but may not be suitable during iterative development of said library.
You need to ldconfig update the dynamic library cache -- it will also create the symbolic links for you.
See eg Section 3.5 of this Linux Documentation Project HOWTO
Related
I want to use a shared library (resides in a custom directory) into an executable.
I've created this makefile
all: SayHello
SayHello: compiledObjects/SayHello.o myLib/libNames.so
g++ compiledObjects/SayHello.o -o SayHello -Icommons -LmyLib -lNames
compiledObjects/SayHello.o: SayHello.cpp
g++ -c SayHello.cpp -o compiledObjects/SayHello.o
myLib/libNames.so: commons/Names.cpp commons/Names.h
g++ -shared -fPIC commons/Names.cpp -o myLib/libNames.so
That create correctly the executable and shared library infact I can Execute the program using this command
LD_LIBRARY_PATH=/custom/path/to/lib/myLib/libNames.so
./SayHello
How can I execute ./SayHello without specify LD_LIBRARY_PATH?
I'm not using any IDE and I'm on linux.
Use the -rpath option to link your executable. See the ld(1) manual page for more information.
P.S. Your makefile appears to have a bug. If you successfully make your program, and immediately run make again, looks like your makefile will attempt to recompile the program again, even though nothing has changed.
After all, the whole purpose of a makefile is to avoid doing unneeded compilations.
The SayHello.o build target should be compiledObjects/SayHello.o.
You need to tell g++ to pass the -rpath option to the linker using -Wl,-rpath. Also, you need to specify a path to the -rpath option.
Putting it all together your last build step should look like this:
SayHello: compiledObjects/SayHello.o myLib/libNames.so
g++ compiledObjects/SayHello.o -o SayHello -Icommons -LmyLib -lNames -Wl,-rpath=/custom/path/to/lib/myLib/
Relative RPATH:
If you want to specify an RPATH relative to your binary you should use
$ORIGIN as a placeholder: -rpath='$ORIGIN/rel/path'.
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 am making a simple hello world program to learn about linking shared libraries in linux. I have managed to compile the main program into an executable with the shared library using the following:
g++ -fPIC -c lab2_hello_main.cpp <--create position independent objects
g++ -fPIC -c lab2_hello_sub.cpp
g++ -fPIC -shared -Wl,-soname=libfuncs.so.1.0 *.o -o libfuncs.so.1.0 -lc <--make the shared library
ln -s libfuncs.so.1.0 libfuncs.so <-- soft links for compiling and running
ln -s libfuncs.so.1.0 libfuncs.so.1
g++ -o hello_dyn lab2_hello_main.cpp -L/mypath -lfuncs <-- Linking the library to main
When I do an ldd on hello_dyn I get an output stating that the library can't be found:
"libfuncs.so.1.0 => not found"
The other libraries it looks for automatically are fine.
Anyone know why this might be?
Your shared library's location is not in the linker's search path. You can confirm this by adding the directory in which your library is located to the LD_LIBRARY_PATH environment variable and then run ldd again. See the ld.so(8) man page for details.
I am compiling a C++ application using GNU g++. The project takes advantage of OpenSSL libraries.
Background
On my machine (a 64 bit CentOS quad core) I compile and link my files.
g++ -g -c -L/usr/local/lib/ -L/usr/lib64/
-I/usr/local/include/ -I/usr/local/ssl/include/
-lcrypto mysrc1.cpp mysrc2.cpp mysrc3.cpp
g++ -L/usr/local/lib/ -L/usr/lib64/ -lcrypto
*.o -o ./myapp.out
My application uses function MD5 which is contained in libcrypto.so. As you can see I specify to g++ the dirs where to search using the -L, -I options and which libraries to look for with the -l<lib-name> option. There are some trivial paths like /usr/local/lib which can be omitted of course, but I specified them because the makefile is parametric.
The problem
My problem is that I can successfully compile my stuff (first command), but linking fails (second command):
/usr/bin/ld: cannot find -lcrypto
collect2: ld returned 1 exit status
make: * [cppsims_par] Error 1
But I did check folders and everything... libcrypto.so is inside /usr/lib64/. What is going on?
It may help if you try strace to find why it failed the file lookup
strace -f -e trace=file g++ -L/usr/local/lib/ -L/usr/lib64/ -lcrypto
*.o -o ./myapp.out
I did find the problem and it is related to this question: ld cannot find an existing library
Actually I had no symlink libcrypto.so and the compiler was not able to find the library...
I had related issue, and resolved it after inspecting the trace.
I had
-L<my/path/to/lib> -llib_some_library
when it should have been
-L<my/path/to/lib> -lsome_library