I'm trying to use clang++ as drop-in replacement for G++. I'm compiling for AArch64, but for linking, clang seems to invoke the native (x86) /usr/bin/ld instead of that from AArch64 GCC suite. The clang command line looks like:
clang++ -target aarch64-linux-gnu -v \
-gcc-toolchain /path/to/aarch64/gcc \
--sysroot=/path/to/aarch64/gcc/aarch64-linux-gnu/libc \
<some other options> <obj files>
And from the verbose output, I get:
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: aarch64--linux-gnu
Thread model: posix
Found candidate GCC installation: /path/to/aarch64/gcc/lib/gcc/aarch64-linux-gnu/4.9.3
Selected GCC installation: /path/to/aarch64/gcc/lib/gcc/aarch64-linux-gnu/4.9.3
"/usr/bin/ld" --sysroot=/path/to/aarch64/gcc/aarch64-linux-gnu/libc ...
I don't get why clang got around choosing the native linker. The link fails for obvious reasons that object files are AArch64 ELF. Compilation lines similar to the above, but they go OK.
Any thoughts?
PS: I'm a novice clang user
I managed to find a solution: GCC accepts -B option to point to the search path where it'd try to locate the utilities. It turns out--although not documented--that clang too accepts this option. For me, having -B point to AArch64 binutils solved the problem. Another suggestion was to add the AArch64 binutils in $PATH.
Related
I am currently trying to use Oracle Linux 6 OS on a SPARC S7 server to run the NPB benchmarks (with OpenMP multithreading support). The OS comes preloaded with gcc 4.4.7, which is missing the Niagara 7 optimizations. I downloaded devtoolset-3 from the Oracle Yum Repository, which has gcc 4.9.2 installed in /opt/rh/devtoolset-3/root/usr/bin. However, when I compile the NPB benchmark using the newer gcc, it automatically links to libraries associated with the older gcc 4.4.7 (located in /usr/lib). This caused my program to segfault during execution. I believe that it is because libgomp 4.4.7 is incompatible with libgomp 4.9.2. I have tried several ways of linking to the libraries in the gcc 4.9.2 folder (which is /opt/rh/devtoolset-3/root/usr/lib/gcc); none of the methods work:
-Xlinker -rpath=lib_location
-Wl -Bstatic
-L lib_location
The closest I got was when using -Wl -Bstatic ~/libgomp.a or -static -L ~/libgomp.a. It fails to find libraries such as libm that reside in the default gcc lib folder (usr/lib).
The actual command used to link is:
/opt/rh/devtoolset-3/root/usr/bin/gcc -O3 -fopenmp -mcmodel=medmid -static -L/opt/rh/devtoolset-3/root/usr/lib/gcc/sparc64-redhat-linux/4.9.2 -o ../bin/bt.W.x bt.o initialize.o exact_solution.o exact_rhs.o set_constants.o adi.o rhs.o x_solve.o y_solve.o solve_subs.o z_solve.o add.o error.o verify.o ../common/print_results.o ../common/c_timers.o ../common/wtime.o -lm -L/opt/rh/devtoolset-3/root/usr/lib/gcc/sparc64-redhat-linux/4.9.2/lib/
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lm
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lrt
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lpthread
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lc
Is there a way I can link just the libgomp library from gcc 4.9.2 while linking the remaining libraries from gcc 4.4.7?
The devtoolset compilers are all using the system libgcc, libstdc++, version 4.4.7, and can therefore not compile e.g. c++11.
I guess the gcc53-c++-5.3.0-1.el6.x86_64.rpm will do. Comes with the internal */gcc53/lib64{libgcc_s.so**, libgomp.so**, libstdc++} (version 5.3.0) ... Provides /usr/bin/{ gcc53, g++53 }
The package was created a year ago ... well tested, as extra compiler. Download link : https://drive.google.com/file/d/0B7S255p3kFXNbTBneHgwSzBodFE/view?usp=sharing
If you're going to do the -Wl,-Bstatic thing, make sure to follow it immediately by -Wl,-Bdynamic to reset to normal after your added library argument. By default, not all system libraries have static versions installed, which is why you get e.g. cannot find -lc.
So you can try this as a modification of your workaround:
-Wl,-Bstatic ~/libgomp.a -Wl,-Bdynamic
Not pretty, and this question deserves a much better answer (this is still pretty much a hack), but it should get the job done for now.
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.
I am trying to cross compile libpng for RaspberryPi on Ubuntu 14.04 (x_64) with zlib
but configure fails with
configure:11400: arm-linux-gnueabihf-gcc -o conftest -g -O2 -I/home/user/RPI_DEV/lib/include conftest.c -lz -lm >&5
/home/user/RPI_DEV/xtools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
configure:11400: $? = 1
configure: failed program was:
....
Because I am using toolchain for arm, arm-ld cant find zlib.
Is there any option for configure not to compile with shared lib but to try with static lib (eg. -static -lz).
Command is
./configure --enable-static=true --enable-shared=false --with-zlib-include="/home/user/RPI_DEV/lib/include" --with-zlib-lib="/home/user/RPI_DEV/lib/lib" LDFLGS="-L/home/user/RPI_DEV/lib/lib" CPPFLAGS="-I/home/user/RPI_DEV/lib/include" -enable-static --host=arm-linux-gnueabihf --prefix=/home/user/RPI_DEV/lib --exec-prefix=/home/user/RPI_DEV/lib
You need to cross build and install zlib into your toolchain before trying to use it in another project.
What you are doing might work but only if you spell LDFLAGS correctly:
LDFLGS="-L/home/user/RPI_DEV/lib/lib"
Note the missing 'A'. I don't know why your second attempt worked, given you had the same misspelling; possibly you had a correct LDFLAGS in your environment?
Anyway there should be a Ubuntu cross-development guide somewhere that explains how to do this. It's slightly off topic but for Gentoo you use 'crossdev' to install the toolchain then a crossdev specific version of the normal package installation mechanism ([host]-emerge) to install zlib into the toolchain.
Also, the arguments --with-zlib-include and --with-zlib-lib are not supported by any current version of libpng I can find. If you are cross-compiling libpng for an RPi (or, indeed, any ARM system) you should be using the latest version of 1.6 that you can find.
Unless someone solves this the RIGHT way, this is hack I've done.
Open configure.ac file
Find and comment out line
AC_CHECK_LIB(z, zlibVersion, , AC_ERROR([zlib not installed]))
Configure will pass wihout check for zlib and then add zlib by hand
LDFLGS="-L/home/user/RPI_DEV/lib/lib -L/home/user/RPI_DEV/lib/lib/libz.a"
Run autoconf
Run ./configure ...
i am very strange about the toolchains, arm-eabi-gcc, arm-linux-gcc, and arm-elf-gcc.
For arm-linux-gcc and arm-elf-gcc, in my opinion, just used the different the libc.
But what's the difference between arm-eabi-gcc and arm-linux-gcc ?
i regard that arm-eabi-gcc dont built in the libc. Am i right ?
if not, could you help to correct me ?
And also why uboot used arm-linux-gcc for the default arm cross compiler ?
As i know, the uboot dont need that libc for dependency.
so that is my problem.
thx!
It's called the target alias or the target-triplet of the toolchain what it's for, basically, is to identify that toolchain from other toolchains and from the native one you have. It tells you what architecture, ABI and target host the toolchain is built for, example:
arm-none-gnueabi: bare metal (no operating system) gnu ABI
arm-linux-eabi: produces binaries for a hosted system (running a Linux environment)
The GCC compiler *gcc is a driver program running other programs. So run
arm-linux-gcc -v -O -Wall helloworld.c -o hellworld-linux-gcc
arm-elf-gcc -v -O -Wall helloworld.c -o hellworld-elf-gcc
arm-eabi-gcc -v -O -Wall helloworld.c -o helloworld-eabi-gcc
and you'll understand the differences. They probably all run some cc1 program doing the translation to assembly code, some as program doing the assembling of assembler code to object code, some ld program doing the linking with some standard libraries. They may also run some collect2 wrapping some linking etc etc.
You may also want to run simply arm-linux-gcc -v or arm-elf-gcc -v or arm-eabi-gcc -v to understand how your compilers have been configured, and their precise version.