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
Related
I built and installed llvm/clang-3.7 from source on my Ubuntu Linux system (I'm building from source because my development environment at work does not have apt-get available). The gcc version is 4.8.2. I followed the clang build instructions at http://clang.llvm.org/get_started.html, and everything worked fine (mkdir build; cd build; cmake -G "Unix Makefiles" ../llvm; make; make install). However, I'm now finding that a program to test Block_copy fails to compile. The program is auto-generated by autoconf when I try to build gnustep-base. The part that fails is:
int
main ()
{
return _Block_copy ();
;
return 0;
}
My compile command is:
clang -o conftest -m64 -march=opteron -mno-3dnow -ggdb -O2 -Wall -I/home/build/GNUstep/Local/Library/Headers -I/home/build/GNUstep/Local/Library/Headers -I/home/build/GNUstep/System/Library/Headers -fgnu-runtime -x objective-c -m64 -L/home/build/GNUstep/Local/Library/Libraries -L/home/build/GNUstep/Local/Library/Libraries -L/home/build/GNUstep/System/Library/Libraries conftest.c -lrt -ldl -lpthread -rdynamic -m64 -fgnu-runtime -L/home/build/GNUstep/Library/Libraries -L/home/build/GNUstep/Local/Library/Libraries -L/home/build/GNUstep/System/Library/Libraries -lobjc -lm
Do I need to build clang with a special option to enable blocks, or should I be linking with another library?
Do I need to build clang with a special option to enable blocks
No. But you may need -fblocks option using the clang binary.
-fblocks
Enable the "Blocks" language feature.
should I be linking with another library?
AFAIK, Yes.
_Block_copy is a part of BlocksRuntime.
BlocksRuntime Block.h
BlocksRuntime runtime.c
Have you compiled compiler-rt? It includes BlocksRuntime. The document explains how to build compiler-rt.
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.
I have some trouble with crosscompiling C++ program which takes advantage of openMP library. I am using Linux Ubuntu 12.04 LTS. I want to obtain executable file runnable on Windows.
I have no problem with compiling my program with OMP with regular g++ command:
g++ a.cpp b.cpp -o OMPres -pg -O3 -I./CBLAS/include -L./ -lcblas
Also when I try crosscompilation without OMP, everything runs perfectly fine:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o res.exe -l gfortran -static
But when I try to crosscompile it with OMP using following command:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I get this error:
a.cpp:41:17: fatal error: omp.h: No such file or directory
compilation terminated.
I found where omp.h file is located on my disk, and added the path to the command. After executing it:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I got another error: x86_64-w64-mingw32-g++: error: libgomp.spec: No such file or directory
As I also have this file on the disk I tried to copy it in various places and finaly it worked when I copied it directly into the directory where compilation takes place. Then it produced another error:
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgomp
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lrt
collect2: ld returned 1 exit status
I don't have a good understanding of how compilers exactly work. I tried to update all mingw-w64 compilers that I could find with apt-cache search but nothing helped. I have no idea what more I can do :(.
First, #nmaier is completely correct in that the Ubuntu x86_64-w64-mingw32 toolchain is crippled, and that you can rebuild the toolchain yourself.
I, however, suggest that you use MXE, which saves you the time of manually compiling gcc and every dependency of it. The steps below should be enough for your purpose:
# Get MXE
git clone https://github.com/mxe/mxe.git && cd mxe
# Settings
cat <<EOF > settings.mk
MXE_TARGETS := x86_64-w64-mingw32.static
JOBS := 4
EOF
# Build gcc, libgomp, blas, and cblas. It will take a while
make -j2 libgomp cblas
# Add toolchain to PATH
# See http://htmlpreview.github.io/?https://github.com/mxe/mxe/blob/master/index.html#tutorial step 4
export PATH=`pwd`/usr/bin:$PATH
# You don't need -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a
# because headers and libraries are installed to standard location and
# I already used `-lcblas -lblas`.
x86_64-w64-mingw32-g++ a.cpp b.cpp -fopenmp -O3 -o res.exe -lcblas -lblas -lgfortran -lquadmath
Your x86_64-w64-mingw32 toolchain appears to have been build without libgomp.
You could check your supplier/distribution if it there additional or variant packages that have libgomp.
Or switch to a different supplier/distribution.
Or you could rebuild (or build in the first place) a cross gcc with --enable-libgomp. This is kinda the hard way.
PS:
Adding paths that do not correspond with your platform, like -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include, is a bad idea in general, and will most certainly fail... This kinda creates a Franken-compiler.
I want to use Android ADB tool on ARM platform. One of the commands in the build script is:
arm-eabi-g++
-I build/libs/host/include/host
-I build/libs/host/include
-I build/libs/host
-I out/host/linux-arm/obj/STATIC_LIBRARIES/libhost_intermediates
-I dalvik/libnativehelper/include/nativehelper
-I system/core/include
-I hardware/libhardware/include
-I hardware/libhardware_legacy/include
-I hardware/ril/include
-I dalvik/libnativehelper/include
-I frameworks/base/include
-I frameworks/base/opengl/include
-I frameworks/base/native/include
-I external/skia/include
-I tools/include
-I out/host/linux-arm/obj/include
-I prebuilt/ndk/android-ndk-r5b/platforms/android-9/arch-arm/usr/include
-c -fno-exceptions -Wno-multichar -fPIC
-include system/core/include/arch/linux-arm/AndroidConfig.h
-D_FORTIFY_SOURCE=0
-DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -O2 -g -fno-strict-aliasing -DNDEBUG -UDEBUG
-DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Wsign-promo -DNDEBUG -UDEBUG
-MD -o out/host/linux-arm/obj/STATIC_LIBRARIES/libhost_intermediates/pseudolocalize.o
build/libs/host/pseudolocalize.cpp
I have made sure I have the latest ndk-r5b installed, which is supposed to resolve the STL problem. However, I am still getting the following error:
In file included from build/libs/host/pseudolocalize.cpp:1:
build/libs/host/include/host/pseudolocalize.h:4:18: error: string: No such file or directory
In file included from build/libs/host/pseudolocalize.cpp:1:
build/libs/host/include/host/pseudolocalize.h:6: error: 'string' in namespace 'std' does not name a type
build/libs/host/pseudolocalize.cpp: In function 'const char* pseudolocalize_char(char)':
build/libs/host/pseudolocalize.cpp:61: error: 'NULL' was not declared in this scope
build/libs/host/pseudolocalize.cpp: At global scope:
build/libs/host/pseudolocalize.cpp:71: error: 'string' does not name a type
Does anyone know how to fix this problem? BTW the building of the intel version of adb works fine by following this link:
http://lackingrhoticity.blogspot.com/2010/02/how-to-build-adb-android-debugger.html
pseudolocalize.cpp is not needed for adb. And NDK toolchain is intended to build with bionic(Android libc). adb requires glibc(GNU libc) to build.
I created a Makefile to compile adb for Linux/ARM. This Makefile makes statically linked adb executable binary for Linux/ARM, thus it works on Android/ARM as well.
standalone Makefile for adb
How to make.
Install Sourcery G++ Lite for ARM and GNU Make.
Download "Android source code".
Save Makefile as system/core/adb/Makefile.
cd system/core/adb; make.
If you need to build the ADB (version 1.0.31) for ARM take a look here.
The repository contains an all-in-one build script and also a pre-compiled binary for ARM.
I see the post is quite old, anyway it helped me.
I did not found
"Sourcery G++ Lite for ARM and GNU Make."
But manage to build/run on/for my ARMv7, following the other steps with gcc 4:4.6.3-1ubuntu5
N/A
Download "Android source code".
Save Makefile as system/core/adb/Makefile.
3b. Edit Makefile to CC= gcc and LD= gcc
cd system/core/adb; make.
You can simply run the command
sudo apt install adb
it can handle ARM architecture
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?