I created a .so file and put it in the location /opt/lib and added this path to LD_LIBRARY_PATH now after this when I try to compile my main program with the following command:
g++ -Wall -I/home/alwin/Development/Calculator/ main.cpp -lcalc -o calculator
I get the following error:
/usr/bin/ld: cannot find -lcalc
collect2: ld returned 1 exit status
Can someone help me with this.
I created the shared library using the code blocks IDE
Add -L/opt/lib to your compiler parameters, this makes the compiler and linker search that path for libcalc.so in that folder.
When you make the call to gcc it should say
g++ -Wall -I/home/alwin/Development/Calculator/ -L/opt/lib main.cpp -lcalc -o calculator
not -libcalc.so
I have a similar problem with auto-generated makes.
You can create a soft link from your compile directory to the library directory.
Then the library becomes "local".
cd /compile/directory
ln -s /path/to/libcalc.so libcalc.so
You need to add -L/opt/lib to tell ld to look there for shared objects.
#Alwin Doss
You should provide the -L option before -l. You would have done the other way round probably. Try this :)
export LDFLAGS=-L/path to lib/ this will solve the error
Related
I am attempting to use the libtommath library. I'm using the NetBeans IDE for my project on Ubuntu linux. I have downloaded and built the library, I have done a 'make install' to put the resulting .a file into /usr/lib/ and the .h files into /usr/include
It appears to be finding the files appropriately (since I no longer get those errors, which I did before installing into the /usr directories).
However, when I create a simple main making a call to mp_init (which is in the library), I get the following error when I attempt to make my project:
mkdir -p build/Debug/GNU-Linux-x86
rm -f build/Debug/GNU-Linux-x86/main.o.d
gcc -c -g -MMD -MP -MF build/Debug/GNU-Linux-x86/main.o.d -o build/Debug/GNU-Linux-x86/main.o main.c
mkdir -p dist/Debug/GNU-Linux-x86
gcc -o dist/Debug/GNU-Linux-x86/cproj1 build/Debug/GNU-Linux-x86/main.o
build/Debug/GNU-Linux-x86/main.o: In function 'main':
/home/[[myusername]]/NetBeansProjects/CProj1/main.c:18: undefined reference to `mp_init'
collect2: ld returned 1 exit status
make[2]: *** [dist/Debug/GNU-Linux-x86/cproj1] Error 1
So, it looks like the linker can't find the function within the library, however it IS there, so I just don't know what could be causing this.
I get the same error if I type the gcc command directly and skip the makefile, I also made sure the static library got compiled with gcc as well.
Edited to Add:
I get these same errors if I do the compile directly and add the library with -l or -L:
$ gcc -l /usr/lib/libtommath.a main.c
/usr/bin/ld: cannot find -l/usr/lib/libtommath.a
collect2: ld returned 1 exit status
$ gcc -llibtommath.a main.c
/usr/bin/ld: cannot find -llibtommath.a
collect2: ld returned 1 exit status
$ gcc -Llibtommath.a main.c
/tmp/ccOxzclw.o: In function `main':
main.c:(.text+0x18): undefined reference to `mp_init'
collect2: ld returned 1 exit status
$ gcc -Llibtommath.a main.c
/tmp/ccOxzclw.o: In function `main':
main.c:(.text+0x18): undefined reference to `mp_init'
collect2: ld returned 1 exit status
I am very rusty on this stuff, so I'm not sure I'm using the right command here, in the -L examples are the libraries being found? If the library isn't being found how on earth do I get it to find the library? It's in /usr/lib, I've tried it with the .a file in the current directory, etc. Is there an environment variable I need to set? If so, how, etc.
I've tried a completely different library (GMP) and had the EXACT same problem. This has got to be some kind of Ubuntu environment issue? Anyone have any idea how to fix this?
The trick here is to put the library AFTER the module you are compiling. The problem is a reference thing. The linker resolves references in order, so when the library is BEFORE the module being compiled, the linker gets confused and does not think that any of the functions in the library are needed. By putting the library AFTER the module, the references to the library in the module are resolved by the linker.
Yes, It is required to add libraries after the source files/objects files. This command will solve the problem:
gcc -static -L/usr/lib -I/usr/lib main.c -ltommath
If the .c source files are converted .cpp (like as in parsec), then the extern needs to be followed by "C" as in
extern "C" void foo();
I already installed libboost, and I made sure the certain library already located in /usr/lib/x86_64-linux-gnu/. I already called #include <boost/filesystem.hpp> in my .cpp file. But, whenever I run this,
g++ -Wall -g -o result.out main.cpp -L/usr/lib/x86_64-linux-gnu -lboost_system
The system gave me
/usr/bin/x86_64-linux-gnu-ld: cannot find -lboost_system
collect2: error: ld returned 1 exit status
Realizing it mentioned ld, I checked my /etc/ld.so.conf.d, and I found a configuration file linked to /usr/lib/x86_64-linux-gnu/. I ran sudo ldconfig, then ran the g++ command again, same result.
I don't know what I'm going to do next, so can anyone help me? I'll provide another information related to this if anyone ask. Thanks in advance.
I'm busy trying to compile and link a c++ program using the following make file
driver.so:driver.cpp
g++ -c driver.cpp -o driver.so
g++ -L/tokenlib/libtokenlib.so driver.so -o linked
but I'm getting the error
g++ -c driver.cpp -o driver.so
g++ -L/tokenlib/libtokenlib.so driver.so -o linked
driver.so: In function `main':
driver.cpp:(.text+0x9): undefined reference to `tokenlib::acquire_token()'
collect2: error: ld returned 1 exit status
make: *** [driver.so] Error 1
and my file hierarchy is
/root
makefile
driver.cpp
/tokenlib
libtokenlib.so
I've been told that adding -Wl,-rpath=./tokenlib to my g++ arguements would solve the problem so I tried like this
driver.so:driver.cpp
g++ -c driver.cpp -o driver.so -Wl,-rpath=./tokenlib
g++ -L/tokenlib/libtokenlib.so driver.so -o linked -Wl,-rpath=./tokenlib
but it still isn't working.
I'm a complete novice and any help would be appreciated.
The linker usually refers to .a (stub) libraries, not to .so files!
-L options specify the paths, the lnker should take in account.
The -l<mystuff> option tries to resolve a library named libmystuff.a from any of the given path's of the -L options, or compiler intrinsic library search paths.
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
So I created a static library with some basic assistance functions in C++ today. I built it with Clang 3.2 (SVN snapshot). However when I try to run a test program that links to it (prog.cpp), I get the following error:
~/Projects/CPP/AssisterLib> g++ prog.cpp -o program -static -L. -lassister
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: cannot find -lm
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
I get the same error with G++ and Clang++. Apparently it can't find libc.a and libm.a, which are both in /usr/lib64 (provided by glibc-devel in OpenSUSE). Adding -L/usr/lib64 does nothing for the error.
Why can't ld find those libraries? Is there a flag that I'm missing?
The problem is likely the use of -static. I would conclude you do not have static version of the libm and libc installed. You can try removing -static to confirm.
The -static flag signals to the compiler that you want your executable to be entirely statically linked, and so it fails if not all the libraries have static versions available.