Unfortunately yes.
I have my shared library compiled, the linker doesn't complain about not finding it but still I get undefined reference error. Thinking that I might be doing something wrong I did a little research and found this nice, simple walkthrough:
http://www.adp-gmbh.ch/cpp/gcc/create_lib.html
which I've followed to the letter but still I get:
$ gcc -Wall main.c -o dynamically_linked -L.\ -lmean
/tmp/ccZjkkkl.o: In function `main':
main.c:(.text+0x42): undefined reference to `mean'
collect2: ld returned 1 exit status
This is pretty simple stuff so what's going wrong?! Is there something in my set up that might need checking/tweeking?
GCC 4.3.2 Fedora 10 64-bit
Change:
$ gcc -Wall main.c -o dynamically_linked -L.\ -lmean
to:
$ gcc -Wall main.c -o dynamically_linked -L. -lmean
You probably meant to do this:
$ gcc -Wall main.c -o dynamically_linked -L./ -lmean
which is OK, but the trailing / is redundant
How was the library created? Libtool?
Show us an ls -l of your current directory, and look at what gcc -v <rest of your command> says (that gives details of what gcc is doing).
Related
I do not know gcc and c well. In my /home/pi/Desktop/intern/adis16227_generic directory I have following 5 files.
ADIS16227.c
ADIS16227.h
Communication.c
Communication.h
main.c
main.c
#include<stdio.h>
#include "Communication.h" // Communication definitions.
int main() {
printf("hello!!\n");
unsigned char status = 0;
status = SPI_Init(0, 1000000, 1, 1);
printf("%u", status);
return 0;
}
Run command:
$ sudo gcc -L /home/pi/Desktop/intern/adis16227_generic main.c -lCommunication
Error:
/usr/bin/ld: cannot find -lCommunication
collect2: error: ld returned 1 exit status
Question:
What I am missing here?
What do I need to run the code?
-l is for libraries, and you never built a library from your Communication.c. The simplest solution is just add Communication.c to your compiler command line.
For larger projects, compile each translation unit separately with the -c switch like this:
gcc -c -Wall -Wextra -pedantic -omain.o main.c
gcc -c -Wall -Wextra -pedantic -oCommunication.o Communication.c
and so on ... (as a suggestion, I added some common warning options here, they help you spot errors)
The resulting .o files are object code. That's already compiled machine code, but with meta-information needed for a linker to link it with other object code into a complete executable.
Then link them all with one command:
gcc -oprogram main.o Communication.o
If you actually want a library from -- say -- Communication.c and ADIS16227.c, you could compile both to object code:
gcc -c -Wall -Wextra -pedantic -oCommunication.o Communication.c
gcc -c -Wall -Wextra -pedantic --oADIS16227.o ADIS16227.c
and then use ar to create a static library from them:
ar rcs libCommunication.a Communication.o ADIS16227.o
Then your initial compiler command would work (with the -lCommunication switch).
Final piece of advice: Never compile as root. This is completely unnecessary. So remove your sudo here.
those options:
-L /home/pi/Desktop/intern/adis16227_generic -lCommunication
suggest that the linker should find libCommunication.a (or .so) in the /home/pi/Desktop/intern/adis16227_generic directory.
But there are only sources in this directory. The linker won't build the sources of your "Communication" library for you.
So you could build the library and link with it:
gcc -c ADIS16227.c Communication.c
ar r libCommunication.a ADIS16227.o Communication.o
but maybe the fastest & quickest way to achieve a successful build would be:
sudo gcc -o main *.c
so it compiles all the files of the directory into the executable called main
Of course, it makes compilation times longer, but maybe it's not noticeable.
First move into the /home/pi/Desktop/intern/adis16227_generic directory:
cd /home/pi/Desktop/intern/adis16227_generic
Then, compile the source:
gcc ADIS16227.c Communication.c main.c -I .
You can now run your compiled program (called by default a.out):
./a.out
You have to compile separatedly files and then compile main with related obj file.
gcc -c Communication.c Communication.h
gcc main.c Communication.o -o main
I have a simple "Hello World!" c program, named hello.c on my desktop:
#include <stdio.h>
int main() {
printf("Hello world!\n");
return 0;
}
I run the following commands.
I pre-process it with : cpp hello.c > hello.i
I compile it with : gcc -S hello.i
I assemble it with : as -o hello.o hello.s
All good so far. But, i'm unable to link it. I've tried, among other commands, these:
ld -o hello.exe hello.o
ld -o hello.exe hello.o -lgcc
ld -o hello.exe hello.o -nostdlib -lgcc
Nothing works. The link errors i get in every single case are :
hello.o:hello.c:(.text+0x9): undefined reference to `__main'
hello.o:hello.c:(.text+0x15): undefined reference to `puts'
How can i link this assembled program hello.o in order to finally produce the executable program hello.exe? What am i missing? [Using Windows 8.1, Mingw version 0.6.2.] Thanks in advance.
Even if your answers to clarification questions are not particularly useful:
Try something like
ld hello.o -lmsvcrt -entry=_main -subsystem=console -o hello.exe
If you want to see the linker command line the standard gcc uses, invoke gcc like so:
gcc test.c -o test -Wl,-v
The last lines output is what you should be using...
If you want to compile something rather than experimenting with tools, don't link it using the linker directly. Use gcc, which will call the linker for you with the right options:
Compile step:
gcc -c hello.c
Link step:
gcc -o hello.exe hello.o
Or all in one:
gcc -o hello.exe hello.c
You can also use a simple Makefile, then run make:
all: hello.exe
I need to include libexplain to my project to do certain job. I install it and add the header libexplain/read.h to my code, so far so good and no error reported by the complier. But when I use the function explain_read() provided by libexplain and build the project it says:
/tmp/cc7NjAw0.o: In function `xl45_read(int, unsigned char*)':
connections.cpp:(.text+0x2f): undefined reference to `explain_read'
collect2: error: ld returned 1 exit status
and the build script is:
#!/bin/bash
echo > ./stdafx.h
g++ -O1 -Wall -o ./local_proxy (*.cpp...here is the source file list) -lz -lpthread -lpcap -L/usr/local/lib
actually when I type
whereis libexplain
in terminal, I get
libexplain: /usr/lib/libexplain.so /usr/lib/libexplain.a /usr/include/libexplain
I do a lot of searches and still have no idea what's going wrong. ):
You need to link your object files with libexplain. You can do it using the -l<library name>, like so:
g++ -O1 -Wall -o ./local_proxy *.cpp -lz -lpthread -lpcap -lexplain -L/usr/local/lib
Note the -lexplain flag. For a library with the a file name like libABC.so, you'd use -lABC to refer to that library. The documentation for link options with GCC can shed more light on it.
I find a problem in the linking process of my application. I did not have the same with gcc 4.5. It tries to link math library with the following command.
gcc -Wall -Wno-unused -MD -o mems_seektest mems_seektest.o -lm -L. -g -DASSERTS -I../src// -I../ -I../src//src -DDEBUG -lmems_internals
and report following error massages:
undefined reference to `sqrt'
Any idea ?
recent gcc/ld uses the --as-needed linker flag as default. Practically, that means libraries have to be specified in the reverse order of dependencies on the command line. If the mems_internals library needs the sqrt function your -lm after -lmems_internals.
gcc -Wall -Wno-unused -MD -o mems_seektest mems_seektest.o -L. -g -DASSERTS -I../src// -I../ -I../src//src -DDEBUG -lmems_internals -lm
I've had the same problem with gcc 4.6.1, even with only one library. This doesn't work:
$ gcc -lm eg.o -o eg
eg.o: In function `foo':
/home/nick/tmp/eg.c:5: undefined reference to `sqrt'
collect2: ld returned 1 exit status
But this does:
$ gcc eg.o -o eg -lm
I hit this because I was using "LDFLAGS=-lm" in my Makefile. Works fine if you use "LDLIBS=-lm" instead.
You didn't tell us what -lmems_internals is, but maybe the unresolved symbol comes from there. The order of the -l options is generally important to the linker, you should always put system libraries last.
You can check where the unresolved symbol comes from by using something like
nm yourLibrary | grep sqrt
if there is a U in front of sqrt the symbol is undefined.
I'd say the linker is using the wrong libm.
Why am I getting an "undefined reference" error using gcc?
I am trying to create a shared object (.so) that exports one function, "external()". I then try to link against the .so but get "undefined reference 'external'". What am I doing wrong here?
File: external.c
int external() {
return 5;
}
File: program.c
int external();
int main(char** argv, int* argc) {
return external();
}
Commands:
$ gcc -fPIC -c external.c
$ gcc -shared -o libexternal.so external.o
$ gcc -L. -lexternal -o program program.c
/tmp/cc3MmhAE.o: In function `main':
program.c:(.text+0x7): undefined reference to `external'
collect2: ld returned 1 exit status
I can even run nm and see that the .so is defining 'external':
Command:
$ nm libexternal.so | grep external
0000040c T external
What am I missing here?
Recent versions of gcc/ld default to linking with --as-needed.
This means if you write -lexternal before the C file the library will automatically get excluded (the order matters when testing if things are "needed" like this)
You can fix this with either of:
gcc -L. -o program program.c -lexternal
gcc -L. -Wl,--no-as-needed -lexternal -o program program.c
The latter of which passes --no-as-needed to the linker, which would cause the library to still be linked, even if you didn't call external() from it.
Note: -Wl,--no-as-needed isn't applied globally to everything that's linked, it's only applied to things that follow it in the command line order. So -lexternal -Wl,--no-as-needed also wouldn't work. This does mean that you can mix and match behaviours though, for example gcc -L. -Wl,--no-as-needed -lexternal -Wl,--as-needed -o program program.c -lmightneed would always link against external, but only link against mightneed if one or both of program.c/libexternal.so caused it to be needed.