I need to build R (http://www.r-project.org/) for Arch Linux ARM running on Raspberry Pi. I am having trouble running ./configure. I have built my own toolchain using crosstool-ng and it does work, I've compiled other applications with it just fine.
The issue appears to be that I cannot link the Fortran libraries to C code. Here is where configure fails:
checking for Fortran 77 libraries of gfortran... -L/home/njackson/bcm2708rpi-toolchain/lib -L/home/njackson/bcm2708rpi-toolchain/lib/gcc/arm-rpi-linux-gnueabi/4.7.3 -L/home/njackson/bcm2708rpi-toolchain/arm-rpi-linux-gnueabi/lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. -lgfortran -lm /home/njackson/bcm2708rpi-toolchain/arm-rpi-linux-gnueabi/lib/libgfortran.a /home/njackson/bcm2708rpi-toolchain/lib/gcc/arm-rpi-linux-gnueabi/4.7.3/libgcc.a
checking for dummy main to link with Fortran 77 libraries... unknown
configure: error: in `/home/njackson/R-2.15.3':
configure: error: linking to Fortran libraries from C fails
See `config.log' for more details
It fails here.
I used the following configure command:
./configure --host=arm-linux-gnueabihf CC=/home/njackson/bcm2708rpi-toolchain/bin/arm-rpi-linux-gnueabi-gcc CXX=/home/njackson/bcm2708rpi-toolchain/bin/arm-rpi-linux-gnueabi-g++ FC=/home/njackson/bcm2708rpi-toolchain/bin/arm-rpi-linux-gnueabi-gfortran MAIN_LD=/home/njackson/bcm2708rpi-toolchain/bin/arm-rpi-linux-gnueabi-ld --with-readline=no
I'd appreciate help getting this compiled. Thanks.
I figured it out.
One should set F77=/path/to/gfortran instead of the FC variable.
Related
I'm trying to compile an example C program that links against PortAudio for a MIPSEL OpenWRT architecture targeting the MT7688 chip.
My starting point is this 351MB Docker image that has a working MIPSEL GNU uclibc toolchain (run source env.sh to set environment variables).
I tried to cross-compile PortAudio at first, but I couldn't get it to output MIPS binaries despite configuring Makefile for --host=mips-openwrt-linux-uclibc. So I copied working libasound.so.2, libportaudio.so.2 and libportaudio.so.2 files from my MIPS device and placed them in both the source folder and /usr/lib, then passed explicit include and linker paths:
$CC I/snowboy/examples/C/portaudio/install/include -L/usr/lib -lasound demo.c -o demo -v
> /bin/ld: cannot find -lasound
collect2: error: ld returned 1 exit status
No dice. I am too dumb to understand GCC linker paths, but I've come this far. Can anyone help me to navigate this cross-compilation minefield?
I am trying to recompile binutils and GCC as a cross-compiler for m68k architecture. I am following these instructions:
http://darkdust.net/writings/megadrive/crosscompiler
However, the process keeps failing on one part or another. I have tried with binutils 2.16.1 and gcc 3.4.6, binutils 2.15 and gcc 3.4.2 and binutils 2.15 and gcc 3.4.6.
This last attempt fails when running "make" on gcc, after making and installing binutils. It gives the following error:
gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H
-I. -I. -I../../gcc-3.4.2/gcc -I../../gcc-3.4.2/gcc/. -I../../gcc-
3.4.2/gcc/../include \
-DTARGET_MACHINE=\"m68k-coff\" \
-c ../../gcc-3.4.2/gcc/collect2.c -o collect2.o
In file included from /usr/include/fcntl.h:289:0,
from ../../gcc-3.4.2/gcc/system.h:214,
from ../../gcc-3.4.2/gcc/collect2.c:30:
In function ‘open’,
inlined from ‘collect_execute’ at ../../gcc-3.4.2/gcc/collect2.c:1535:20:
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:50:4: error: call to
‘__open_missing_mode’ declared with attribute error: open with O_CREAT or
O_TMPFILE in second argument needs 3 arguments
__open_missing_mode ();
^
Makefile:1364: recipe for target 'collect2.o' failed
make[1]: *** [collect2.o] Error 1
make[1]: Leaving directory '/home/gabriel/src/gcc-build/gcc'
Makefile:23339: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2
I don't expect to fix this error, but does anyone know of a combination of binutils and gcc release that work? Should I be using a certain version of gcc to recompile gcc successfuly?
Thanks for any insight you may have on this!
EDIT:
My linux has GCC 5.4.0 so I just downloaded the 5.4.0 source to try and rebuild that for m68k cross-compiling. I now get the following error when running "make" on the gcc source:
*** Configuration m68k-unkown-coff not supported
What could be the cause of this? Is it because I need an older version of GCC? (the binutils version i'm using definately supports the m68k target). The tutorial I'm using always defines "--target=m68k-coff", should that instead be "--target=m68k-unkown-coff"?
EDIT 2:
So I tried compiling for m68k-elf but now I get this error:
checking for m68k-elf-gcc... /home/gabriel/src/gcc-build/./gcc/xgcc -B/home/gabriel/src/gcc-build/./gcc/ -B/opt/m68k/m68k-elf/bin/ -B/opt/m68k/m68k-elf/lib/ -isystem /opt/m68k/m68k-elf/include -isystem /opt/m68k/m68k-elf/sys-include
checking for suffix of object files... configure: error: in `/home/gabriel/src/gcc-build/m68k-elf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
I ran download_prerequisites before building so it should not be a problem with the MPC library. Any idea how to move on? I need assembler only so I don't mind what the format of the object files is. Thanks!
I used to do pretty much what you are doing right now.
My advice is to use crosstool-ng (http://crosstool-ng.github.io), as it does pretty much everything in an automated manner.
If you are studying m68k assembly, I used to host a modified version of gcc-explorer by Matt Godbolt (https://godbolt.org/). You can find a runnable docker image here (https://hub.docker.com/r/esantoro/acso-explorer/) and some more details here (https://znpy.wordpress.com/2017/05/08/decommisioning-acso-explorer-santoro-tk/)
Hope it helps,
znpy
you can build most versions with a current Linux. To install the prerequisites have a look at https://github.com/bebbo/amiga-gcc
unpack the gcc archive, e.g. to /opt/cross/gcc-6.5.0
create a separate build folder, e.g. /opt/cross/xcc-6.5.0 - never build inside gcc's source folder!
create the prefix folder, that's where binaries are installed to, e.g. /opt/cross/gcc65
ensure that these folders exist and are writable, then
configure from within that build folder using an absolute path for configure
cd /opt/cross/xcc-6.5.0/
/opt/cross/gcc-6.5.0/configure --target=m68k-elf --program-prefix=m68k-elf- --enable-languages=c,c++ --prefix=/opt/cross/gcc65 --disable-libssp --disable-nls --disable-multilib
make all-gcc
make install-gcc
I'm also running the compiler explorer for 68k gccs at https://franke.ms/cex/
I am trying to compile my C socket programming files using gcc with -lnsl option on MAC OS but it gives me this error:
ld: library not found for -lnsl
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
This is the gcc command:
gcc -o server -lnsl server.c
I looked all over the internet but I can't find sth relevant to help me. How to install the missing library? Or should I reinstall gcc? Please help!
Thanks!
Mac OS X has no libnsl. Functions that live in libnsl on Linux are found in the standard C library on Mac OS X. No additional flags are necessary for building programs that use these functions.
If your program works on Linux and doesn't work on a Mac, then your program has a bug that is triggered on Mac OS X but not on Linux. No amout of fiddling with linker flags is likely to change that.
I'm trying to make an "C" application for my NXP(Freescale) imx6 that Debian OS installed on it. My host machine is Ubuntu 16.04. I'm using eclipse as an IDE and I can manage to cross compile until today. I use arm-linux-gnueabihf-gcc as an compiler and arm-linux-gnueabihf-ld as an linker. I added -lasound option to my linker parameter, but still can not build the application. I get an error
arm-linux-gnueabihf-ld: cannot find -lasound
I think I don't have the libasound.so file on my Ubuntu (Host) machine and my linker couldn't link to library to my application.
I copied the libasound.so file from my ARM machine to my host machine to the /home/user/Downloads folder, but still couldn't compile.
Is there a step to use ALSA library in Cross Compilation project before build?
Here is the output of build operation
Building target: tihc_linux_application
Invoking: GCC C Linker
/usr/bin/arm-linux-gnueabihf-ld -static -L/home/user/Downloads -pthread -lasound -o "main" ./src/main.o
/usr/bin/arm-linux-gnueabihf-ld: mode armelf_linux_eabi
/usr/bin/arm-linux-gnueabihf-ld: cannot find -lasound
You ask for static link (via -static) but provide shared library so ld probably ignores it (to be sure you can run with -Wl,--verbose). One option is to cross-compile libalsa from scratch and then use resulting static lib to link your app. Another option is to search for pre-compiled gnueabihf libalsa somewhere...
I want to link an existing shared library (FlashRuntimeExtensions.so) to my C-code while compiling my own shared library. But whatever I try I always get the same error; that the file is in a wrong format. Does anybody have an idea on how to solve this?
Here is my compile command:
$ g++ -Wall ane.c FlashRuntimeExtensions.so -o aneObject
FlashRuntimeExtensions.so: could not read symbols: File in wrong format
collect2: ld gaf exit-status 1 terug
Your command line tries to generate x86 code and link it to ARM code using the native g++ available in your distribution.
This will not work. Use the Android NDK available here: http://developer.android.com/tools/sdk/ndk/index.html
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
In general .so will be linked using -l.
for example, pthread -lpthread we use.
gcc sample.c -o myoutput -lpthread
But as per #chill's statement, what you are doing in command is correct only.
I suggest you to refer the following link.
C++ Linker Error SDL Image - could not read symbols
It should be an architecture mismatch. I faced this problem once, I have solved it by building the libs in same target platform and it is obvious. If you are using linux or Unix like OS you can see that by file command and if you are using windows you can see that using Dependency Walker. You need to make sure that all the libs matches architecture.