I'm feeling a bit thick, but when I run through even basic examples provided on http://code.google.com/p/protobuf-c/wiki/Examples, I keep getting the following build errors:
/tmp/cc19catp.o: In function `main':
packit.c:(.text+0x13): undefined reference to `amessage__descriptor'
packit.c:(.text+0xb6): undefined reference to `amessage__get_packed_size'
packit.c:(.text+0xdb): undefined reference to `amessage__pack'
collect2: ld returned 1 exit status
I'm compiling with the following command:
gcc -o pack -lprotobuf-c packit.c
Anyone else have this problem? I feel I'm missing something basic.
gcc -o pack packit.c amessage.pb-c.c -lprotobuf-c
You must compile and link the proto-c-generated code.
Also, in general, when foo depends on bar, foo should precede bar in the linker command.
Related
I can’t figure out why I’m getting these compilation errors:
gcc -o Compil obj/MillerRabin.o obj/main.o -L. -L/usr/lib/ -Wl,-rpath=/home/---------/Documents/AC20_Cyrpto -lgmp -lCommon -ltest -lprimeGen
./libtest.so: undefined reference to `__gmpz_set_str'
./libtest.so: undefined reference to `__gmpz_set_ui'
./libtest.so: undefined reference to `__gmpz_add_ui'
./libtest.so: undefined reference to `__gmpz_clear'
./libtest.so: undefined reference to `__gmpz_init'
./libtest.so: undefined reference to `mpzPrint'
collect2: error: ld returned 1 exit status
Makefile:61: recipe for target 'Compil' failed
make: *** [Compil] Error 1
These errors are coming from libs/test/test.c, I’m using a make file that a friend of mine made, and I haven’t really looked into how they work yet.
So what’s weird is that in my libs folder I have another .c file that’s using gmp (libs/Common/common.h and mpzfunctions.c), and that one doesn’t give me any errors. If I move my test function to the main the compilation works.
If anyone knows how to fix this, it would be great! Thanks.
Symbols from libraries are applied in order. So when you write:
-lgmp -ltest
It means that symbols used in libgmp will be looked up in libtest but not vice versa.
Apparently, your libtest requires functions from libgmp, so you need to apply them in the opposite order.
As a rule of thumb, external libraries should always go last because they do not generally require symbols from your libraries.
So without knowing too much, I 'd guess that the order should be:
-lCommon -lprimeGen -ltest -lgmp
It looks to me like you will want to remove -lgmp from LINK_FLAGS and add it somehow to the end of the link command.
Trying to compile some C code (a simple select * from dual with oracle (11g) db connection on Linux, generated from .pc thru proc command) through the gcc command and I always get an error.
undefined reference to 'sqlcxt'
I tried to link to libraries I saw on different forums around the web, but got nothing (error still occurs):
gcc -o proc_test proc_test.c -L$ORACLE_HOME/lib/libclntsh.so
and I still get
/tmp/ccAW4Imj.o: In function `main':
proc_test.c:(.text+0x3ea): undefined reference to `sqlcxt'
proc_test.c:(.text+0x57c): undefined reference to `sqlcxt'
proc_test.c:(.text+0x60d): undefined reference to `sqlcxt'
collect2: ld returned 1 exit status
Can anyone help with that?
The answer is:
gcc -o proc_test proc_test.c -L$ORACLE_HOME/lib -lclntsh -m32
I just needed to put -m32 cause libs and linux have different bits
This is my very first experience with the MPG123 library, and I'm a bit confused.
I found a small example about using this library, with libao, but when i try to compile I got an error.
This is the example code "Play local files": http://hzqtc.github.io/2012/05/play-mp3-with-libmpg123-and-libao.html
I compile with: gcc -O2 -o play play.c -lmpg123 -lao
The error I get is:
/tmp/ccmEoxBp.o: In function `main':
play.c:(.text.startup+0x8d): undefined reference to `mpg123_encsize'
collect2: ld returned 1 exit status
What am I missing?
You have an old version of the mp123 library, according to the release notes it was added in 26.0.26
https://github.com/gypified/libmpg123/blob/master/NEWS.libmpg123
26.0.26
- Added mpg123_encsize().
- Added flag MPG123_SKIP_ID3V2.
I can ssh to my schools Ubuntu 11.04 server where I have to submit my code and this links fine:
ME#SCHOOL:~/309/project2$ make
gcc -lm treesort.c -o treesort
ME#SCHOOL:~/309/project2$
My local machine is running Ubuntu 12.04 and here is the compiler output for the same code, but using the NetBeans makefile:
gcc -lm -o dist/Release/GNU-Linux-x86/treesort build/Release/GNU-Linux-x86/sortFns.o build/Release/GNU-Linux-x86/treesort.o
build/Release/GNU-Linux-x86/treesort.o: In function `processargs':
treesort.c:(.text+0x144): undefined reference to `log'
collect2: ld returned 1 exit status
Using the command line on my local machine with the same code and makefile from the first example:
ME#MYCOMPUTER:~/Documents/CSCI/309/project2$ make
gcc -lm treesort.c -o treesort
/tmp/ccY5GqF1.o: In function `processargs':
treesort.c:(.text+0x2b5): undefined reference to `log'
collect2: ld returned 1 exit status
make: *** [all] Error 1
ME#MYCOMPUTER:~/Documents/CSCI/309/project2$
This is really quite irritating, and I can't figure out why it works on the server and not on my local machine. I found this question, but it didn't help.
Put -lm at the end of the link line. The order of sources,objects and (archive) libraries on the link line matters, and yours is wrong.
If putting -lm at the end of the link line doesn't help, you have some bogus library called libm.{a,so} somewhere on your system, and you should figure out where it came from, and get rid of it.
You cam find out which libm your linker is finding with gcc -Wl,-t ...
I'm trying to build a project for ARM uClibc environment, but I've some functions missing. Can not find which library shall I include to resolve dependancies. nm do not help me to search, since it says on most of libs coming with toolchain:
nm: ./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/libuClibc-0.9.32.1.so: no symbols
Here is the output from GCC:
./host/usr/bin/arm-unknown-linux-uclibcgnueabi-gcc
-Wl,-rpath,./host/usr/lib/
-Wl,-rpath,./host/usr/../lib/
-Wl,-rpath,./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/
-Llibzway -o test_so main.o -lzway
-L./host/usr/lib/
-L./host/usr/../lib/
-L./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/ -lpthread
-lxml2 -lz -lm
./host/usr/lib/libxml2.so: warning: gethostbyname is obsolescent, use getnameinfo() instead.
./host/usr/lib/libxml2.so: undefined reference to `fcntl64'
./host/usr/lib/libxml2.so: undefined reference to `fopen64'
./host/usr/../lib/libz.so: undefined reference to `lseek64'
./host/usr/lib/libxml2.so: undefined reference to `stat64'
./host/usr/lib/libiconv.so.2: undefined reference to `mbrtowc'
./host/usr/lib/libiconv.so.2: undefined reference to `_stdlib_mb_cur_max'
./host/usr/lib/libiconv.so.2: undefined reference to `wcrtomb'
./host/usr/lib/libxml2.so: undefined reference to `open64'
collect2: ld returned 1 exit status
make: *** [test_so] Error 1
UPD:
I've copied uClibc from the target host and explicitely defined asked to link with it:
./host/usr/bin/arm-unknown-linux-uclibcgnueabi-gcc
-Wl,-rpath,./host/usr/lib/
-Wl,-rpath,./host/usr/../lib/
-Wl,-rpath,./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/
-Llibzway -o test_so main.o -lzway
-L./host/usr/lib/
-L./host/usr/../lib/
-L./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/
-luClibc-0.9.31
-lpthread -lxml2 -lz -lm
./host/usr/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.5.3/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld:
errno: TLS reference in ./host/usr/bin/../arm-unknown-linux-uclibcgnueabi/sysroot/lib/libpthread.so.0 mismatches non-TLS definition in ./host/usr/lib/libuClibc-0.9.31.so section .bss
./host/usr/bin/../arm-unknown-linux-uclibcgnueabi/sysroot/lib/libpthread.so.0: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [test_so] Error 1
This is much bayond my knowledge of cross-compilation. Any idea?
It sounds like you have several issues going on:
You seem to be trying to use the host's copy of libxml2.so. This is not going to work. You need one built for your target system and its libc.
Your uClibc was compiled without large file support. Go back and fix the build options or uClibc. It's not strictly necessary (a correctly built libxml2.so linked against uClibc will work without doing this), but using the pre-large-file interfaces is really backwards and will unnecessarily limit your programs.