I am trying to compile an example C program and link it to some static library files using:
gcc -I /usr/local/include -L /usr/local/lib -l libsundials_cvode.a -l libsundials_nvecserial.a cvRoberts_dns.c -o cvRoberts_dns.o
(I am sure that the library files and include files directories above are correct.)
The error I get is:
/usr/bin/ld: cannot find -llibsundials_cvode.a
collect2: ld returned 1 exit status
I have two questions:
1) Am using the -L and -l options correctly?
2) The above error is b/c gcc is looking for the library file in the wrong location right? I tried to fix this by setting $LD_LOAD_PATH via my terminal to /usr/local/bin. I still get the above error. How do I fix this?
Thanks!
-Rohan.
Try -lsundials_cvode instead - delete the 'lib' and '.a' parts
Note that LD_LOAD_PATH is for locating dynamic libraries at run-time, not during compilation.
Edit:
I just tried that. The change addresses the cannot find library error but
now I am faced with many "undefined reference to" errors. Does this mean
the linking of the library files has failed somehow? How do I correct this?
It means that there are other symbols that need to be resolved that are not in the library you linked. Note that you need to change both libraries (you have two on the command line). Also perhaps they are in the wrong order.
Related
I am writting an mqtt communication script where I am using the paho library.
the files .so exist in the /home/chaima/paho.mqtt.c/build/output directory.
but when trying to compile the code using the gcc compiler, I am getting this error
/usr/bin/ld: cannot find -l/home/chaima/paho.mqtt.c/build/output
I've tried so many solutions but none of them worked for me.
please if you need further information let me know about it.
Thank you in advance.
The -l switch asks the linker to use a certain library. It should followed by the name of a library or a file system path to the library.
/home/chaima/paho.mqtt.c/build/output is a path to a directory, not a library.
The -L switch tells the linker to use a certain directory as a place to look in for libraries. After -L/A/B/C and -L/D/E/F, the linker will look in the directories /A/B/C and /D/E/F for libraries. For example, with -L/A/B/C -L/D/E/F -l foo, the linker will look for a file named /A/B/C/foo.extension and /A/B/C/foo.extension, where extension is one of the file name extensions used for libraries, such as a or so in foo.a or foo.so.
To get the linker to use your libraries in /home/chaima/paho.mqtt.c/build/output, use -L/home/chaima/paho.mqtt.c/build/output followed by -lName0 -lName1 -lName2 …, where Name0, Name1, Name2, and such are the names of your libraries. You an also ask the linker to use a library by giving its full path and name with no switch, as in /home/chaima/paho.mqtt.c/build/output/foo.so.
Both the ld command (to invoke the linker directly) and the gcc command (an overall command that will compile, link, and perform other tasks) accept these switches. In the future, read the manual page (also called the “man page”) or other documentation of the tools use use. The man page for ld explains what its -l and -L switches do. On Unix systems, you can usually see the man page for ld by executing man ld and the man page for gcc by executing man gcc. The current GCC documentation is also here.
I'm trying to use pcap functions, but it giving me compiler error:
project.c:(.text+0x140): undefined reference to `pcap_open_offline'
I have installed library and while compiling I give "-lpcap" at the and as it advised in many forums.
What can be wrong, please?
You need to understand what the arguments evoke into the linker.
I am supposing you are using Linux system with gcc, using ld as linker (note that this could change depending on the system and the linker used).
In such case, -Lpath tell the linker where to look for the libraries that you tell it that are needed to be linked with your program to create the final binary. For example -L/usr/lib.
when you type in for example:
# gcc -L/usr/lib -lcap my_program.c -o my_program
You are telling the linker to append /usr/lib to the list of paths to locate libraries, and to link the dynamic library "libcap.so" with your program.
Other modifiers for the path used to locate libraries is LD_LIBRAY_PATH (the name of this environment variable could change from one system to another, review the manual of your linker).
As you are using "-lcap" the error you get look to be related with the fact that no path is found where libcap.so exist. Locate that file into your system and pass the argument
-L/path/to/the/directory/that/contain/libcap.so
By the way, try to run this before any other thing and recompile:
# sudo ldconfig
I've recently begun using a new ELF loader. The loader requires you to link your applications with ld -r.
The problem is that GCC no longer warns me of undefined functions, and then the loader (obviously) fails to find them.
How do I link with ld -r, and get the undefined symbols method.
I am using ld -r for relocation purposes, so a different way to include relocations will also work for me.
In your makefile, define an intermediate target where you link with all the options but the -r one, to a file in the temporary directory (so you're sure not to use it).
If this phase succeeds, then proceed to the real link with the -r option.
I am trying to use sqlite3 in my Eclipse C project, I have added sqlite3.h and its address: /usr/include/ to linker, but still get this error message:
make all
Building target: SQLiteTest
Invoking: GCC C Linker
gcc -L/usr/include/ -o "SQLiteTest" ./hello.o -lsqlite3.h
/usr/bin/ld: cannot find -lsqlite3.h
collect2: error: ld returned 1 exit status
make: *** [SQLiteTest] Error 1
I guess I have to add it to compiler as well, have tried many ways, but none of them worked.
Thanks for help
When compiling and linking C programs:
the -I/some/where/include option is used to specify where headers (include files) are found,
the -L/some/where/lib option is used to specify where libraries are found,
the -lname option is used to say "link with the library libname.so or libname.a"
The suffixes on libraries vary by platform — choose from .sl, .sa, .dll, .lib, .dylib, .bundle, to name but a few alternative extensions.
The -L/usr/include option is unlikely to be correct. Headers are stored in /usr/include, and not libraries. Changing that to -I/usr/include is unnecessary; the compiler will search in /usr/include anyway. If the sqlite3.h header is in /usr/include, it will be found without options. If it is somewhere else, like perhaps /usr/local/include or /opt/sqlite3/include, then you may well need to specify -I/usr/local/include or -I/opt/sqlite3/include on the command line. In each case, you might also need -L/usr/local/lib or -L/opt/sqlite3/lib as well. (Note that your compiler might, but probably won't, search in /usr/local automatically.)
As noted in the comments, you would not specify -lsqlite3.h on the command line. It would mean that there was a library such as libsqlite3.h.so somewhere on your system, which is an implausible name. Most likely, you should just specify -lsqlite3 on the linking command line.
MPICH2 is installed in C:\Program Files\MPICH2. There are two subdirectories (of interest), \include which contains .h files, and \lib which contains .lib files.
The readme that comes with MPICH2 has the following instructions:
create a makefile
add –I...mpich2\include
add –L...mpich2\lib
add –lmpi
add the rules for your source files
compile
Since there are no other rules in my project, I don't create a makefile, I just go to the command line and try compiling like this:
g++ -I"C:\Program Files\MPICH2\include" main.cpp -L"C:\Program Files\MPICH2\lib" -lmpi
This gives me a fistful of undefined reference errors on every single MPI symbol in the code. I spent hours trying to fix it, juggling -I, -L and -l switches around, shuffling the order of the parameters, even copied all the .lib files into the same directory as my source, but nothing seems to work.
What kind of voodoo is needed to get this thing to link?
EDIT: I think I found the problem: here's an excerpt of the linker's output in verbose mode (adding -Wl,--verbose to the compile command):
attempt to open C:\Program Files\MPICH2\lib/libmingwex.dll.a failed
attempt to open C:\Program Files\MPICH2\lib/mingwex.dll.a failed
attempt to open C:\Program Files\MPICH2\lib/libmingwex.a failed
attempt to open C:\Program Files\MPICH2\lib/mingwex.lib failed
attempt to open C:\Program Files\MPICH2\lib/libmingwex.dll failed
attempt to open C:\Program Files\MPICH2\lib/mingwex.dll failed
attempt to open C:\Program Files\MPICH2\lib\libmingwex.a failed
Apparently, the linker adds a / instead of a \ to the directory names I supply it with (except when looking for the lib___.a format for some reason), which is obviously not a valid path. Is there any way to tell the linker to use backslashes instead of slashes?
This also caught my eye:
attempt to open /mingw/lib/libmingwex.a succeeded
So I tried compiling like this:
g++ -I"/Program Files/MPICH2/include" -L"/Program Files/MPICH2/lib" objManager.cpp ongom.cpp io.cpp main.cpp -lmpi -lcxx
But I still get the same undefined reference errors.
GCC is able to find your library. Otherwise it would report: cannot find -lmpi.
Somehow it happens that the routines cannot be found in that library. I managed to compile an example with this syntax:
g++ -I../include cpilog.c ../lib/mpi.lib ../lib/mpe.lib
I did that inside msys though. And my directory does not contain spaces.
After removing libmpi.a file, this also works:
g++ -I../include -L../lib cpilog.c -lmpi -lmpe
try adding -lmpicxx (the lib for the c++ bindings), and make sure the -l... come after the cpp source file *. this works for me:
g++ -Iinclude -Llib test/cxxpi.cpp -lmpicxx -lmpi
EDIT: re: "undefined reference to 'MPI_Comm_rank'": could it be that your are mixing up / using c and / instead of c++? MPI_Comm_rank seems to be the c binding - the c++ binding would be MPI::Comm::Get_rank(). maybe try compiling your program as c, or, if you want to use c++, using the proper bindings (see cxxpi.cpp in the examples dir)?
* http://newsgroups.derkeiler.com/Archive/Comp/comp.parallel.mpi/2006-08/msg00036.html
I had the similar problem resulting from linking 32-bit object files with 64-bit MPICH library. Linking with 32-bit libmpi.a solved the problem.
I had a similar issue with mingw: for those library files with a .lib ending, I had to put the name of the library without the ending (e.g. -llibboost_system-mgw34-mt when the filename is libbboost_system-mgw34-mt.lib). For library files with a .a ending, I had to put the name of the library excluding the starting "lib" and the trailing .a (e.g. -lws2_32 for libws2_32.a).
So in your case - try -llibmpi (or whatever your file is called without the .lib ending), perhaps it's the same issue.
from: http://www.mingw.org/node/98/revisions/358/view
Note: some paths were printed with “/” as the path separator while some other was printed with “\” as the path separator. I've substitued all with “/” as MinGW GCC accept both.
So I would not put too much time into finding a way to correct the path seperator. Is your library compiled for mingw?
perhaps: http://www.mingw.org/wiki/LibraryPathHOWTO helps you a bit further.