I'm trying to compile a program with glib. I set up all the include paths so compilation goes through without errors but linker can't find glib.
Invoking: Cross GCC Linker
arm-linux-gnueabihf-gcc -L/home/ja/raspberrypi/rootfs/usr/local/lib -L/home/ja/raspberrypi/rootfs/lib/arm-linux-gnueabihf -o "daemon_test" ./src/gpio/gpio.o ./src/can/can_stuff.o ./src/can/libsocketcan.o ./src/daemon_test.o -lglib-2.0 -lwiringPi
/home/ja/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lglib-2.0
makefile:32: recipe for target 'daemon_test' failed
collect2: error: ld returned 1 exit status
make: *** [daemon_test] Error 1
I have a cross compiler set up for my raspberry pi. it's composed of eclipse and a gcc compiler running on debian.
it seems obvious that the linker can't find the proper file.
On my target raspberry pi I've installed libglib2.0-dev and a test program builds fine. So I used rsync to update my cross compiler's rootfs
rsync -rl --delete-after --safe-links pi#192.168.2.160:/{lib,usr,opt} $HOME/raspberrypi/rootfs
my include paths are set to the same values as come out from pkg-config on my rpi(adjusted for rootfs location)
pkg-config --libs --cflags glib-2.0
as I was writing this I did a search for "libglib" on both rpi and my cross compiler. there's a libglib-2.0.so on my rpi, but in my crosscompiler it's a libglib-2.0.so.0, they are both same size.
I removed the ".0" and got a new error
warning: libpcre.so.3, needed by /home/ja/raspberrypi/rootfs/lib/arm-linux-gnueabihf/libglib-2.0.so, not found (try using -rpath or -rpath-link)
and a bunch of undefined refferences. the thing is, that file exists in the same location as libglib-2.0.so(renamed form libglib-2.0.so.0)
-L/home/ja/raspberrypi/rootfs/lib/arm-linux-gnueabihf
anyone has any ideas what to do? I spent my whole day on this..
Related
I have an application that links again SDL and cairo that I would like to cross-compile on ubuntu for win64. I used this excellent blog post to get SDL cross compiling and I've used another blog post to cross-compile zlib, libpng and libpixman.
However, I now get a linker error trying to compile my minimal test program:
$ make cairotest.exe
x86_64-w64-mingw32-gcc -o cairotest.o -c cairotest.c -I/usr/x86_64-w64-mingw32/include/SDL2 -Dmain=SDL_main -I/home/jshaw/x86_64-w64/include/cairo -I/home/jshaw/x86_64-w64/include/pixman-1 -I/home/jshaw/x86_64-w64/include/libpng16
x86_64-w64-mingw32-gcc -o cairotest.exe cairotest.o -L/usr/x86_64-w64-mingw32/lib -lmingw32 -lSDL2main -lSDL2 -mwindows -L/home/jshaw/x86_64-w64/lib -lcairo
collect2: error: ld returned 1 exit status
Makefile:13: recipe for target 'cairotest.exe' failed
I should mention that this test program works correctly if I just use SDL2 without any cairo code, so I suspect something is wrong with the cairo library that I cross-compiled. How should I go about diagnosing the problem?
Looking at your Makefile it appears as though your are using normal pkg-config for discovering your Cairo libs. CAIRO_LDFLAGS := $(shell $(PKG_CONFIG) cairo --libs). This will find the path to your host libraries, which is presumably a different architecture than the target. An architecture mismatch like that can really cause strange problems with the linker. I believe you should be looking for something like usr/x86_64-w64-mingw32/bin/pkg-config.
Other things to try;
Run the compilation commands manually, as the makefile could be suppressing output.
Also, when running the command, add the -v flag to the command line to get the verbose output to better figure out where the issue is.
My program uses the GNU Multiple Precision Arithmetic Library to deal with numbers of an arbitrary size. I successfully compile it using GCC with:
gcc main.c -o diff -g -lgmp
However, when I try to use the MinGW crosscompiler compiler, I get the following error:
i686-w64-mingw32-gcc main.c -o diff.exe -g -lgmp
main.c:3:46: fatal error: gmp.h: No such file or directory
#include <gmp.h>//For files of arbitrary size
I then tried to tell it exactly where the header file was:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g -lgmp
/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
Ok, so I figure now it successfully found the header, but cant find the library. So I tried again:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g -L/usr/lib -lgmp
/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
I guess I need to specify the exact files to use, so I tried this:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g /usr/lib/libgmp.so
/usr/lib/libgmp.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
So, I honestly don't know what to do and I'd really really appreciate your help.
First, a disclaimer: the cross-compiler you are using is neither distributed by, nor supported by MinGW.org, whom I represent; if you are looking for a pre-compiled solution, you should seek it from the distributor of the specific cross-compiler itself.
That said, I can offer the following insight, (which will apply, in general, to any cross-compiler): the headers you find in /usr/include, or in /usr/local/include, and the libgmp.so which you find in /usr/lib, or in /usr/local/lib, are intended for use with your native platform compiler. They are not suitable for, and cannot be used with your MinGW cross-compiler; attempting to do so will surely never work. Thus, you have two options:
Ask your cross-compiler distributor to provide a pre-compiled copy of gmp.dll, (or at the very least, a compatible import library, although you may need the gmp.dll to distribute with your own application anyway), and any associated header files, and/or equivalent statically linkable library, for use with your cross-compiler.
Use your cross-compiler to build gmp.dll yourself, then install it, its associated headers, and perhaps also its associated import library and/or equivalent statically linkable library, into the same prefix-path as the cross-compiler itself.
I'm trying to write a very small, very simple project using PJSIP. But I'm already stuck on the first step, incorporating PJSIP in my project. I'm trying to build and compile on a Ubuntu 14.04 system using an arm-linux-gnueabihf-gcc cross compiler. For the coding itself I'm using Eclipse CDT, but the crosscompiling part is working in a normal order.
I downloaded de pjproject-2.3 folder to my system, configured it with this command:
./configure --host=arm-linux-gnueabihf CFLAGS='--sysroot=/home/david/rpi/rootfs' LDFLAGS='--sysroot=/home/david/rpi/rootfs'
The /home/david/rpi/rootfs folder is where I copied the rootsystem of my Pi. I then ran 'make dep' and 'make'. I copied all the static libraries *.a to my Eclipse project folder and added the libraries to the linker (-l).
But when I want to build I get the following error:
Invoking: Cross G++ Linker
arm-linux-gnueabihf-g++ -L"/home/david/workspace/VoIPBenchmark" -L/home/david/rpi/rootfs/usr/lib -L/home/david/rpi/rootfs/usr/lib/arm-linux-gnueabihf --sysroot=/home/david/rpi/rootfs/ -o "VoIPBenchmark" ./src/SipImplemantation.o ./src/SipImplementationPJ.o ./src/Timer.o ./main.o -lpjsua2-arm-unknown-linux-gnueabihf -lpjsua-arm-unknown-linux-gnueabihf -lpjsip-ua-arm-unknown-linux-gnueabihf -lpjsip-simple-arm-unknown-linux-gnueabihf -lpjsip-arm-unknown-linux-gnueabihf -lpjsdp-arm-unknown-linux-gnueabihf -lpjmedia-audiodev-arm-unknown-linux-gnueabihf -lportaudio-arm-unknown-linux-gnueabihf -lpjmedia-codec-arm-unknown-linux-gnueabihf -lpjmedia-arm-unknown-linux-gnueabihf -lspeex-arm-unknown-linux-gnueabihf -lgsmcodec-arm-unknown-linux-gnueabihf -lsrtp-arm-unknown-linux-gnueabihf -lilbccodec-arm-unknown-linux-gnueabihf -lresample-arm-unknown-linux-gnueabihf -lpjnath-arm-unknown-linux-gnueabihf -lpjlib-util-arm-unknown-linux-gnueabihf -lpj-arm-unknown-linux-gnueabihf -lpthread -lm -lrt -lasound -llinphone
/home/david/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: /home/david/workspace/VoIPBenchmark/libsrtp-arm-unknown-linux-gnueabihf.a(ctr_prng.o)(.text+0x8c): unresolvable R_ARM_ABS32 relocation against symbol `ctr_prng'
/home/david/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [VoIPBenchmark] Error 1
I googled some and tried to add -fPIC in the ./configure step above, recopied the libraries, but without result. Does anyone know what this message is saying me, and better yet, knows a solution?
This problem has been resolved. I was using a library that also linked to the srtp library, this evidently conflicted. So I am now not using the library that causes the problem.
I am working with c++ code for a physics simulation, which uses a lot of external libraries (like GSL and cern`s ROOT). Trying to recompile project I encountered problems with linking. When running compilation of final file via:
g++ -fno-inline -O2 -fpic -o main.out ${ROOTINCS} main.o ext.o ${ROOTLIBS} $(objects2)
with :
objects2= many .o files made by us
ROOTLIBS=-L/usr/local/lib/root -lTree -lRIO -lNet -lHist -lMathCore -lCore -lGraf -lGraf3d -lGpad -lMatrix -lThread -lCint -lPhysics -lPostscript -lRint -lSpectrum -lg
ROOTINCS=-pthread -m64
I get annoying error:
/usr/bin/ld: /usr/local/lib/root/libHist.so: undefined reference to symbol 'gRandom'
/usr/local/lib/root/libMathCore.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
The problem is nm -C run on libMathCore states 'gRandom' is declared there. Also -lMathCore is present in my command line.
When I run ld to check if it understands the flag:
ld -L/usr/local/lib/root -lMathCore --verbose 2>/dev/null
it does not complain and tries to link properly.
According to https://stackoverflow.com/a/24675715/3602168 order of libraries is correct in my linking (libHist uses libMathCOre and therefore is stated first).
Compilation runs under g++ 4.8.2 on ubuntu 14.04, 64 bit
Converting comment to answer:
Have you tried moving $(objects2) before ${ROOTLIBS}? I think the issue may be that you have libraries specified before the object files that use them.
I am attempting to compile a C program with multiple files on window platform. However, when I make it, errors are occurred. I have already tried to modify command in makefile but still could not fix it.
This is my GCC command:
gcc -o "SYSMONTR" $(OBJPATH)/chkdsksp ../chkdsksp.c -g -I"$(DB2PATH)/include" -I"$(MYLIBDIR)" $(MYIQDIR)/iqclilib.a $(OBJPATH)/icrou.a -lc -ldb2 -lnsl -L"$(DB2PATH)/lib"
This is result:
gcc -o "SYSMONTR" ../../iLINKOBJ/chkdsksp ../chkdsksp.c -g -I"C:/Program Files/IBM/SQLLIB/include" -I"../../iLINKCLIB" ../../iLINKIQOBJ/iqclilib.a ../../iLINKOBJ/icrou.a -lc -ldb2 -lnsl -L"C:/Program Files/IBM/SQLLIB/lib"
../../iLINKOBJ/chkdsksp: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
makefile:49: recipe for target `SYSMONTR' failed
make: *** [SYSMONTR] Error 1
What could cause such error and what should I do with it? Using cygwin on Window (IDE: Eclipse).
Any supports will be appreciated.
If chkdsksp is an object file built by another team to run on AIX, you cannot expect it to function -- or even be recognized by your compiler -- on Cygwin. You must contact that team and get a) the source code or b) a version of the object file compiled for your platform (and tested).