I am trying to cross-compile linux for an ARM architecture.
The host is an X86 machine running ubuntu-jaunty. I downloaded a cross-compile toolchain for ARM from http://ftp.arm.linux.org.uk/pub/armlinux/toolchain/. I downloaded the 2.95.3 version of the toolchain.
The problem I am having is that GCC is passing in some default flags by itself that is causing GCC to then output error:
/usr/local/arm/2.95.3/bin/arm-linux-gcc -specs=/home/feroze/wnr834m/marvell_WNR834M/gcc_specs -D__KERNEL__ -I/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -DLED_DUAL_COLOR -DFOR_ROUTER -I/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk/arch/arm/mach-mv88fxx81/Soc/gpp/ -Uarm -fno-common -pipe -mapcs-32 -D__LINUX_ARM_ARCH__=5 -march=armv5 -mtune=arm9tdmi -mshort-load-bytes -msoft-float -Uarm -march=strongarm -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
cc1: bad value (strongarm) for -march= switch
make[1]: *** [init/main.o] Error 1
make[1]: Leaving directory `/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk'
I checked the whole makefile, and could not find any place where LINUX_ARM_ARCH_5 and -march=armv5 are being defined. I am defining -march=strongarm in the makefile, but then it gets appended by theh ARMv5 defines.
So, I created a defs file from gcc, modified it to only have options for ARMv4, and then used it by specifying the -specs= option. However, that still doesnt solve the problem.
Can somemone help? How do I resolve this?
Thanks!
feroze
The -march flag is set in arch/ARM/Makefile, and depends on the machine you selected in your config file. If you don't want the armv5 flag, be sure to select the correct architecture in the config file.
You should assume the kernel appended CFLAGS are right (provided your config is ok) and if your toolchain does not support one of them, then you have no choice but to cross compile a toolchain by yourself, using the original crosstol script that should work with 2.95.3
Edit : original answer
What are you trying to build ?
a 2.95.3 toolchain is fairly ancient. You should try a more recent toolchain. You can find a precompiled one here
Pick the EABI one to start.
This is not a direct answer to your problem, but if you are building the linux kernel, you should not need to mess with the Makefiles. You will get more help if you can get a more "standard" toolchain.
This won't strictly help you eliminate the issue, but you can do gcc -dM -E <empty_file.c> or gcc -dM -E -x c /dev/null to print out a listing of all the predefined #defines for gcc. Combine -dM with another flag like your -march and you might be able to track down what's causing your #define issue.
Be sure to check your environment variables, as they can persuade make to do unexpected things.
If the Makefile includes another file, it could be modifying CFLAGS before CC is called. Can you print the contents of CFLAGS just before the CC call?
Related
This is a most vexing issue. When I run my makefile I see two sysroot in the output:
ubuntu#ubuntu:~/Desktop/LatestAndroidstuff/CmE_source_DAL_1.7_3564/CmCompact$ make
platform/wince/WibuCmHID/rules.mak:31: WibuCmHID only for Windows CE
/home/ubuntu/my-android-toolchain/bin//arm-linux-androideabi-gcc -I./ -I./external/hidapi/include -Os -std=c99 -Wall -Wextra -fno-short-enums -fno-strict-aliasing --sysroot=/home/ubuntu/my-android-toolchain/sysroot --sysroot=/home/ubuntu/android-ndk-r13b/platforms/android-14/arch-arm -o obj/release/android/armeabi-v7a/static/w_refcount.o -c base/w_refcount.c
In file included from base/w_refcount.c:29:0:
./base/w_define.h:31:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
rules.mak:54: recipe for target 'obj/release/android/armeabi-v7a/static/w_refcount.o' failed
make: *** [obj/release/android/armeabi-v7a/static/w_refcount.o] Error 1
If I edit the failing command and remove the extra sysroot (the second one), it works.
/home/ubuntu/my-android-toolchain/bin//arm-linux-androideabi-gcc -I./ -I./external/hidapi/include -Os -std=c99 -Wall -Wextra -fno-short-enums -fno-strict-aliasing --sysroot=/home/ubuntu/my-android-toolchain/sysroot --sysroot=/home/ubuntu/android-ndk-r13b/platforms/android-14/arch-arm -o obj/release/android/armeabi-v7a/static/w_refcount.o -c base/w_refcount.c
Problem is, I have looked all over the makefile. The makefile is simple enough:
WBSMAK_ANDROID_NDK_HOME=/home/ubuntu/android-ndk-r13b
SYSROOT=/home/ubuntu/my-android-toolchain/sysroot
ANDROID_TOOLCHAIN_DIR=/home/ubuntu/my-android-toolchain/bin/
WBSMAK_ANDROID_CC=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-gcc
WBSMAK_ANDROID_LD=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-ld
WBSMAK_ANDROID_AR=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-ar
WBSMAK_ANDROID_RANLIB=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-ranlib
SHELL := /bin/bash
AR := WBSMAK_ANDROID_AR
CC ?= WBSMAK_ANDROID_CC
LD ?= WBSMAK_ANDROID_LD
RANLIB := WBSMAK_ANDROID_RANLIB
In order to make the file pick up sysroot:
CFLAGS_ARCH := --sysroot=${SYSROOT}
But there is no mention at all in the makefile about that other second sysroot nor that path that shows up. Also, I looked and made sure it's not picking up an environment variable.
ubuntu#ubuntu:~/my-android-toolchain$ printenv | grep SYSROOT
ANDROID_SYSROOT=
LINARO_SYSROOT=/home/ubuntu/linaro-toolchain-4.6/arm-unknown-linux-gnueabi/sysroot
SYSROOT=/home/ubuntu/my-android-toolchain/
The environment sysroot it pointed to where I want it.
If I move the Android NDK folder and all its stuff out of the path, that is nowhere in the makefile, then I get the error. If I have the folder where the extra sysroot is, then the library compiles and links, but it crashes on the Android device, which is Android 21, not 14. I don't know why it's always Android 14. Could I be missing some setting somewhere? Perhaps when I created the standalone tools using make-standalone-toolchain.sh something hardcoded went in so the calls to /home/ubuntu/my-android-toolchain/bin/arm-linux-androideabi-gcc always searches for the android-14 path?
Very vexing problem. I have been all over the makefile. I don't know why the gcc keeps picking up that android 14 sysroot. Could I be only providing for the compilation but the linking is pulling up a default sysroot?
Alright the issue appears to have been a carefully sidelines .mak file in a subfolder that was looking for a string in a string of an existing field and on finding that, was using ANDROID_ARCH for the --sysroot in the actual gcc call. But to the credit of who wrote it, it did have the other -march setting needed for proper compile and linking of the android native module.
Moral of the story: always surf around the folders and take a glance at everything.
(of course my app still crashes but that's another matter to find that out... )
I use Asus router (based on ARMv7 proc) with Advanced Tomato installed
on it as my ARMv7 developer platform. I install compiler (gcc - 5.4.0-1)
plus dependencies and libFTDI (libftdi1 - 1.3-1) from OpenWRT Linux
repo. OpenWRT does not provide libftdi-dev so I copied ftdi.h file from libFTDI download page to /opt/include directly. I try to compile program taken directly from libFTDI samples. The
compiler command is:
gcc -v -Wl,-rpath=/opt/usr/local/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 -L/opt/lib -O2 -pipe -march=armv7-a -mtune=cortex-a9-fno-caller-saves -mfloat-abi=soft -l ftdi1 d.c -o d
But compilation fails because:
/opt/bin/ld: cannot find -lftdi1
But there is /opt/usr/local/lib/libftdi1.so linked to libftdi1.so.2
My LD_LIBRARY_PATH looks like this:
/lib:/usr/lib:/usr/local/lib:/opt/lib:/opt/usr/lib:/opt/include:/opt/usr/local/lib:/opt/usr/include
So what the problem is?
I dont know why (probably bug) but for compiler taken from OpenWRT repo, MUST have wanted library in /opt/lib. So simply copy libftdi1.so.2.3.0 file and linking it to libftdi1.so resolved problem. That means that it does not use correctly LD_LIBRARY_PATH variable. Finally compilation command looks like this:
gcc -v -Wl,-rpath=/opt/usr/local/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 -L/opt/lib -O2 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -l ftdi1 arco.c -o arco
From my point of view - topic closed
I would like to prepare GNU toolchain for bare metal ARM to use it with Geany IDE. There are some tutorials like this one: Building the GNU ARM Toolchain for Bare Metal but I do not understand few steps.
First of all, everyone who uses Linux OS implicitly has gcc, binutils and gdb so why to download others? Secondly all tutorials tell me to configure gcc with something like that: *./configure --target=arm-elf. What does it even do ? Does it just force me to call gcc in command line using arm-elf-gcc instead of gcc or does it change some internal options of my gcc ?
So far I have prepared makefile but I am still not sure about compiler options. I have not changed any gcc configure options and I call compiler with such flags:
CFLAGS = -Wall -std=c99 -march=armv7-m -mtune=cortex-m0
Can I prepare toolchain just with calling gcc with proper arguments or do I need to make some changes in gcc configuration ?
GCC and its target
GCC is always configured to emit binaries for a specific target. So normally the gcc which is already available on Linux has the target "i486-linux-gnu". You can't cross-compile to an ARM target using this compiler.
So you need to install another GCC configured for that target; then GCC and the other programs normally have a prefix indicating the target: In your case the prefix is arm-none-eabi, and then you call that GCC using arm-none-eabi-gcc. You can have multiple GCC installations, they do not interact (if they interact, you have probably screwed up something - always install in separate directories, if you do it manually).
Installing
If your Linux distribution provides a package, you could just install that one (on Debian this is "gcc-arm-none-eabi").
You can download a pre-compiled package: GNU Tools for ARM Embedded Processors.
You can try to compile one. Not really easy, if you want correct multi-libs.
If your Linux distribution provides a package > 4.8.0, you should try that one.
If you want to have multiple versions installed (and be able to switch between them easily), the second option is possibly better. I stopped compiling a GCC for ARM when the second option was available.
Cross-compiling
In your Makefile you have to make sure that the cross-compiler is used. You could use $(CC) in your Makefile, and assign it like this:
TOOLCHAIN = arm-none-eabi-
CC = $(TOOLCHAIN)gcc
Compiler flags for Cortex-M0 are -mcpu=cortex-m0 -mthumb -mfloat-abi=soft which is by convention assigned to CFLAGS
CFLAGS += -mcpu=cortex-m0 -mthumb -mfloat-abi=soft
Then a (simple) rule to compile .c to .o looks like
%.o: %.c
$(CC) $(CFLAGS) -o $# -c $<
Tutorials which use the arm-elf- prefix are out-dated. Currently arm-none-eabi- is in use.
If one installs an R package that requires compilation via
R CMD INSTALL package.tar.gz
from the bash, R uses by default the gcc compiler. It happened now that my R-package throws a warning on Cran with a 'clang' compiler setup, that doesn't appear using the gcc compiler.
In order to reproduce the warning now on my local machine, I would like to adjust the local compiler settings to those used on the Cran-check servers.
I found out that it should be possible to change the R default compiler by creating a Makevars.in file somewhere in the home folder, but I cannot find where it has to be located and what has to be written there in order to make R to use 'clang' with certain warning flags enabled instead of 'gcc'.
Has anybody already switched on his/her Linux system the R default compiler from gcc to clang and could give me a hint how to do that?
My favourite method (and I think I detailed that here before) is to use the file ~/.R/Makevars where I set
CFLAGS += -O3 -Wall -pipe -pedantic -std=gnu99
CXXFLAGS += -O3 -Wall -pipe -Wno-unused -pedantic
#VER=-4.6
#VER=-4.7
VER=-4.8
CC=ccache gcc$(VER)
CXX=ccache g++$(VER)
SHLIB_CXXLD=g++$(VER)
FC=ccache gfortran
F77=ccache gfortran
MAKE=make -j8
#CXX=clang++
#CC=clang
and more as it also allows you to switch to clang++ instead of g++ and more.
I use ccache here too in order to accelerate repeated builds -- very useful for R packages where you may alter the package code but not the src/ files.
An alternative approach would a shell-script wrapper in which you set CC, CXX and everything else you want to modify.
This question already has answers here:
How to link to a shared library without lib* prefix in a different directory? [duplicate]
(2 answers)
Closed 2 years ago.
I compiled a few libraries using Eclipse-CDT on windows. However, when I tried to compile them under linux gcc keeps giving me the error /usr/bin/ld: cannot find -lrequestedLib. I'm using the exact same build settings between the two environments (namely I made sure to add the directories that contain the libraries i need to link to). I'm sure the system has read access rights to the files as well. I'm not sure what to make of this. Please help.
Edit: These are the commands that ecplise runs to build the library:
gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib
Edit 2: The command that renders the error is the second of the two, resulting in the /usr/bin/ld: cannot find -lrequestedLib being output.
Edit 3: I've confirmed that requestedLib.so is a x86_64 binary.
If you don't want to pass -L command line options to gcc(1), be sure to add the path containing the libraries to /etc/ld.so.conf or /etc/ld.so.cond.d/<something>.
Once you've installed your libraries you also need to run ldconfig(8) by hand. (Most new users forget this step because typical package managers take care of this for you when installing new libraries.)
gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib
When building 64-bit shared libraries on x86_64, the -fPIC flag is usually required, or you get a recompile with -fPIC error at shared library link time.
Since you didn't use -fPIC, yet your link succeeded, you are likely using (non-default) gcc that targets i*86 (that is, produces 32-bit output). You can confirm that by running file libToMake.so.
You didn't show that command that actually fails (the one that produces cannot find -lrequestedLib error). I am guessing that that command is using a different gcc (default one?), that targets x86_64. If it looks something like
gcc main.c -L/home/me/lib -lrequestedLib
that command will ignore /home/me/lib/librequestedLib.so (because you can't link together 32-bit and 64-bit code), and will continue searching for librequestedLib elsewhere. When it can't find a 64-bit version of librequestedLib, it will produce the error message you are gettiing.