i have made a static library using the ar command after an object creation using gcc -o file.o -c file.c.
Now i'm trying to use the gcc to link this library in the compilation with a command similar to this
gcc -I /PathInclude -L /PathStaticLib -lm \
-std=c99 -o file file.o -lstatic_library_name
with static_library_name i mean that the file is named
libstatic_library_name.a
Since the files structure is quite complex (because basically in the compiling i also substitute some macro definition etc) i don't post all the code, do you have any thought on what is going on? if not what kind of info could i provide to you in order to help me?
PS. there aren't a lot o files, but the internal structure is a bit complicated to explain in few words, so... let me know what do you need.
I can give you the make file content if you need, is not complicated.
PS. The command is...
gcc -I../CModels -L../CModels/ -std=c99 -o ref_approx_bs3_log2_4_4_1ulp_arch1
ref_approx_bs3_log2_4_4_1ulp_arch1.o -lm -lmy_float
The error is
ref_approx_bs3_log2_4_4_1ulp_arch1.o: In function `cogen_fp_bs3_log2_4_4_1ulp_arch1':
ref_approx_log2.c:(.text+0x2229): undefined reference to `cast'
ref_approx_log2.c:(.text+0x22d0): undefined reference to `cast'
ref_approx_log2.c:(.text+0x22f7): undefined reference to `cast'
ref_approx_log2.c:(.text+0x232e): undefined reference to `sumFP'
ref_approx_log2.c:(.text+0x2350): undefined reference to `diffFP'
ref_approx_log2.c:(.text+0x2375): undefined reference to `mulFP'
ref_approx_log2.c:(.text+0x239c): undefined reference to `sumFP'
collect2: ld returned 1 exit status
Using
nm my_float.a
the output is
my_float.o:
0000000000000ca8 T _Z11castToFixedyPyyyy
0000000000000a0c T _Z12splitIntFracyPyS_yy
0000000000000324 T _Z28rightShift_and_round2NearestyyPyyy
000000000000005c T _Z3ldzy
0000000000000132 T _Z3mulyyy
000000000000048a T _Z4castyPyyyyy
0000000000000000 T _Z4maxuyy
000000000000002e T _Z4minuyy
00000000000014dc T _Z5mulFPyyPyyy
0000000000000cc2 T _Z5sumFPyyPyyy
000000000000147a T _Z6diffFPyyPyyy
0000000000000300 T _Z9ldzFormatyy
U __gxx_personality_v0
So i guess the library .a is ok...
As per the gcc manual, AFAIR, there should be no space in between -L or -I and the path. Change your command to
.. -I/PathInclude -L/PathStaticLib ...
Error says that the references to cast, sumFP, diffFP , mulFP are not defined. Need to make sure that they are defined in the library.
Related
I have following two source codes and want to link them.
// test.c
#include <stdio.h>
void lib2();
void lib1(){
lib2();
return 0;
}
// main.c
#include <stdio.h>
int main() {
return 0;
}
I've used gcc -c main.c and gcc -c test.c to generate objects files
$ ls *.o
main.o test.o
and I've used ar rcs test.a test.o command to generate static library(test.a) from object file test.o
Then, I tried to build executable by linking main.o with test.a or test.o. As far as I know, a static library file(.a extension) is a kind of simple collection of object files(.o). so I expected both would give same result: error or success. but it didn't.
Linking with the object file gives undefined reference error.
$ gcc -o main main.o test.o
/usr/bin/ld: test.o: in function `lib1':
test.c:(.text+0xe): undefined reference to `lib2'
collect2: error: ld returned 1 exit status
$
but linking with the static library doesn't give any error and success on compilation.
$ gcc -o main main.o test.a
$
Why is this happening? and how can I get undefined reference errors even when linking with static libraries?
If your code contains a function call expression then the language standard requires a function definition exists. (See C11 6.9/3). If you don't provide a definition then it is undefined behaviour with no diagnostic required .
The rule was written this way so that implementation vendors aren't forced to perform analysis to determine if a function is ever called or not; for example in your library scenario the compiler isn't forced to dig around in the library if none of the rest of the code contains anything that references that library.
It's totally up to the implementation what to do, and in your case it decides to give an error in one case and not the other. To avoid this, you can provide definitions for all the functions you call.
You might be able to modify the behaviour in the first case by using linker options such as elimination of unused code sections. Another thing you can do is call lib1() from main() -- this is still not guaranteed to produce an error but is more likely to.
Force the linker to do some work use -flto option and the error will go away.
ld does not search libraries for objects which are not used it only searches for symbols used in object files. Imagine that you have a library where some functions require defined callbacks. If you do not have them in every program you link against the library even if you do not use those functions.
I expected both would give same result: error or success. but it didn't.
Your expectation is incorrect. A good explanation of the difference between .o and .a with respect to linking is here.
I am trying to build an example program which uses WinPcap-functions. I’m working under Windows 7 64 Bit edition with MinGW. I am able to compile the C-code to an object file, but I can’t link against wpcap.lib.
My linker call looks like this:
gcc -L ../../lib/x64 send_packet.o -lwpcap -o WinPcapTest.exe
With this call I get the following errors:
undefined reference to pcap_open
undefined reference to pcap_sendpacket
undefined reference to pcap_geterr
Obviously I am not linking against wpcap.lib, but I don’t know why. The library is definitely found. If I change the lib include path for example, I get this error:
cannot find -lwpcap
Why does the linker find the lib but does not link against it? Thanks for your help.
Try listing you libraries after binary definition. As far as I remember, with provided gcc command, ld would be symbol matching for pcap symbols between send_packet.o and libwpcap.lib but not with WinPcapTest.exe. I would suggest moving -lwpcap at the end:
gcc -I ..\..\..\Downloads\WpdPack_4_1_2\WpdPack\Include ..\send_packet.c -L ..\..\..\Downloads\WpdPack_4_1_2\WpdPack\Lib\x64 -O0 -g3 -Wall -o WinPcapTest.exe -lwpcap
I am trying to use Curl in C.
I visited Curl official page, and copied sample source code.
below is the link:
http://curl.haxx.se/libcurl/c/sepheaders.html
when I run this code with command "gcc test.c",
the console shows message like below.
/tmp/cc1vsivQ.o: In function `main':
test.c:(.text+0xe1): undefined reference to `curl_global_init'
test.c:(.text+0xe6): undefined reference to `curl_easy_init'
test.c:(.text+0x10c): undefined reference to `curl_easy_setopt'
test.c:(.text+0x12e): undefined reference to `curl_easy_setopt'
test.c:(.text+0x150): undefined reference to `curl_easy_setopt'
test.c:(.text+0x17e): undefined reference to `curl_easy_cleanup'
test.c:(.text+0x1b3): undefined reference to `curl_easy_cleanup'
test.c:(.text+0x1db): undefined reference to `curl_easy_setopt'
test.c:(.text+0x1e7): undefined reference to `curl_easy_perform'
test.c:(.text+0x1ff): undefined reference to `curl_easy_cleanup'
I do not know how to solve this.
You don't link with the library.
When using an external library you must link with it:
$ gcc test.c -lcurl
The last option tells GCC to link (-l) with the library curl.
In addition to Joachim Pileborg's answer, it is useful to remember that gcc/g++ linking is sensitive to order and that your linked libraries must follow the things that depend upon them.
$ gcc -lcurl test.c
will fail, missing the same symbols as before. I mention this because I came to this page for forgetting this fact.
I have the same problem, but i use g++ with a make file.
This is a linker issue.
You need to add option -lcurl on the compiler and on the linker.
In my case on the make file:
CC ?= gcc
CXX ?= g++
CXXFLAGS += -I ../src/ -I ./ -DLINUX -lcurl <- compile option
LDFLAGS += -lrt -lpthread -lcurl <- linker option
Gerard
Depending how bad things are you might need an -L/somewhere in LDFLAGS to let the linker know where the libraries are. ldconfig is supposed to pick them up and find them on every boot but on a new machine it can take a little prodding, like adding a directory to your /etc/ld.so.conf.
During my project's linking process the linker fails with the following errors unless I make an explicit call in my code to one of of the stub functions (i.e. _sbrk):
c:/toolchains/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libg.a(lib_a-abort.o): In function `abort':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\stdlib/../../../../../newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit'
c:/toolchains/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libg.a(lib_a-signalr.o): In function `_kill_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
c:/toolchains/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libg.a(lib_a-signalr.o): In function `_getpid_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
c:/toolchains/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libg.a(lib_a-sbrkr.o): In function `_sbrk_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk'
collect2: ld returned 1 exit status
I am aware that I need some stubs functions that newlibc requires and I have a "C" file that contains all of the ones mentioned above as missing and I am also positive that the file is being compiled and added to an archive file (*.a) that is later linked.
I am calling the linker using the following commands
arm-none-eabi-gcc -L -T linkerscript.ld -nostartfiles -Wl,-Map,$(TARGET).map -lc archive.a
My question is simple (I hope) How can I make sure that the linker links my stub functions into the elf file without having to make an explicit function call from one of my project files?
I think those errors you're getting refer to the linker not being able to find the appropriate library. My first suspicion is in how you're using your arguments, specifically your specification of archive directory (-L) and the archive.a file. I'm thinking it should go like this:
arm-none-eabi-gcc -L. -T linkerscript.ld -nostartfiles -Wl,-Map,$(TARGET).map -lc -larchive
where the changes I'd make are:
-L. means use the current directory to look for library files to link.
-lc specifies to use the archive file libc.a.
-larchive specifies to use the archive file libarchive.a.
For more info I'd suggest checking out theGNU GCC reference.
Pass --verbose to gcc to see exactly where archive.a is showing up in the list of libraries and objects passed to the linker.
You need to arrange things so that archive.a is searched after libg.a since that's the archive that contains the objects that end up with undefined references.
You might be able to fix this by adding -lg before archive.a on the gcc command line.
-lg should in libg.a earlier than where it's getting pulled in now by default and more importantly pull it in before archive.a.
I'm using MinGW. I have some code which calls malloc and a few other general purpose functions. When I type:
gcc TestCode.c
I get an a.exe file, it works perfect, and I don't get any warnings.
If I type this:
gcc -c TestCode.c -o TestCode.o
ld *.o
I get a whole bunch of warnings such as:
TestCode.o:TestCode.c:(.text+0xa): undefined reference to `__main'
TestCode.o:TestCode:(.text+0x2e): undefined reference to `printf'
TestCode.o:TestCode:(.text+0x42): undefined reference to `_strerror'
TestCode.o:TestCode:(.text+0x69): undefined reference to `snprintf'
TestCode.o:TestCode:(.text+0x7e): undefined reference to `malloc'
TestCode.o:TestCode:(.text+0x93): undefined reference to `_strerror'
TestCode.o:TestCode:(.text+0xb1): undefined reference to `sprintf'
TestCode.o:TestCode:(.text+0xcf): undefined reference to `free'
I'm assuming this is an issue with how I'm calling the linker. As such, I'll only post the code if it isn't clear what the problem is. I'm hoping this is an easy fix and that I simply forgot to include some super obvious library when linking.
It appears that your ld doesn't link any libraries by default. From your error messages, it looks like you need at least the C runtime and libc. Use gcc to link to get some handy defaults linked in for you:
gcc -c TestCode.c -o TestCode.o
gcc *.o
If you really want to use ld directly, you're going to need to figure out the names of your C runtime library and libc. For example (assuming libraries named libcrt and libc):
ld *.o -lcrt -lc
As Carl Norum said, you can pass object files to gcc and it'll know it doesn't need to compile them - it just passes them on to the linker (whether or not you're compiling other source files in the same invocation).
And you should probably do that because there's a fair amount of detail that goes into linking in the CRT and windows support libraries (unless you have a very specific need to not use the default runtime). My current MinGW setup links in the following items along with my object files:
crt2.o
crtbegin.o
-ladvapi32
-lshell32
-luser32
-lkernel32
-lmingw32
-lgcc
-lmoldname
-lmingwex
-lmsvcrt
crtend.o
Use the --verbose option to see how gcc links for you.