I'm trying to build a GCC/newlib cross compilation toolchain targeting an embedded OS on RISC-V. For this purpose, I need to modify the virtual addresses that binaries are linked at.
One way to achieve this is to modify the default linker script that ships with the toolchain.
I'm trying to find the best location in the involved components (newlib, binutils, gcc) where I can tweak the default linker script that is shipped with the toolchain.
For some platforms, newlib already provides partial or complete linker scripts. It seems for RISC-V the default linker script produced by binutils is used.
I'm fine with patching binutils, but I can't find how the RISC-V linker script is actually built or how I would modify anything in it. Any pointers are appreciated!
The different linker scripts for riscv are build from :
binutils/ld/scripttempl/elf.sc
binutils/ld/emulparams/elf32lriscv*
binutils/ld/emulparams/elf64lriscv*
You will need to modifiy these files or create your own and modify the Makefiles.
Related
I have a C++ project that I'm currently building using dynamic linking to various system libraries. It's on a RHEL 7 system. I've been using devtoolset-9 to get a more modern version of g++ (the system one is 4.8.5, I think). It all works fine, but I'd like to now build a static executable that I will be able to run on a non-RHEL linux system. I've tried specifying -static-libstdc++, but it appears to still be dynamically linked, looking at the ldd output. I've read that devtoolset compilers use some link-time trickery to link in both the system libstdc++ dynamically and any new C++ functionality statically. Is this true? It doesn't work for me; if I copy the executable over to the non-RHEL system and try to run it, I get a bunch of things like this (from memory, so hopefully correct):
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found
Is there any way to build a fully static executable using g++ from devtoolset-9? Thank you.
Can we configure gcc running on intel x64 architecture to produce binary for ARM chip by just passing some flags to gcc and not using a cross compiler.
Short: Nope
Compiler:
gcc is not a native crosscompiler, the target architecture has to be specified at the time you compile gcc. (Some exceptions apply, as for example x86 and x86_64 can be supported at the same time)
clang would be a native crosscompiler, and you can generate code for arm by passing -target=arm-linux-gnu, but you still cant produce binaries, as you need a linker and a C-library too. Means you can run clang -target=arm-linux-gnu -c <your file> and compile C/C++ Code (will likely need to point it to your C/C++ include paths) - but you cant build binaries.
Rest of the toolchain:
You need a fitting linker and toolchain too, both are specific to the architecture and OS you want to run at.
Possible solutions:
Get a fitting toolchain, or compile your own. For arm linux you have for ex. CrossToolchains if you are on debian, for barebones you can get a crosscompiler from codesourcery.
Since you were very vague, its not possible to give you a clearer answer
I have a weird Linux system where most of the software is compiled against Glibc and some others against uClibc.
Since the Linux is a standard distro when I launch and executable the standard dynamic linker is invoked (/lib/ld.so.1) from glibc.
I'm looking for a way to specify the dynamic loader before launching any executable so when I want to run software which was compiled against uClibc I can define the launching mechanism to use uClibc dynamic loader (/lib/ld-uClibc.so.0).
Any ideas?
I'm looking for a way to specify the dynamic loader before launching any executable so when I want to run software which was compiled against uClibc
You should be specifying the correct dynamic loader while building against uClibc, using the linker --dynamic-linker argument. E.g.
gcc -nostdlib -Wl,--dynamic-linker=/lib/ld-uClibc.so.0 \
/lib/uClibc-crt1.o main.o -L/path/to/uClibc -lc
Just put the full path to the dynamic linker before calling the executable, for example:
/home/x20/tools/codescape-2016.05-3-mips-mti-linux-gnu/2016.05-03/sysroot/mipsel-r2-hard/lib64/ld-2.20.so out.gn/mipsel/d8
d8 is the binary we want to execute and ld-2.20.so is the dynamic linker
Looks to me as if you need to set PT_INTERP to point to an alternative interpreter that in turn prefers your prefered ld.so device. See the man page for elf(5). See readelf to dump what you have and see; you are trying to change ld-linux-xxx.so.x to whatever you come up with.
Actually, it looks to me as if you just want to point to your alternative ld.so as the INTERP.
I got a little confused when it comes to QT and cross compiling
appliations for my arm-linux:
So far I have a linux running on my AT91SAM9263-EK and an appropriate
filessystem including QT libs build via buildroot.
Also I have build QT-4.8 on my ubuntu.
Now I want to build an example application:
I created a makefile in an examples folder in QT on my ubuntu using
qmake; I used the given qmake.conf in mkspecs/qws/linux-arm-g++.
when executing make I get an error because it includes qatomic_i386.h
and the message "error: impossible constraint in 'asm'".
this header file does obviously not match to my arm toolchain.
my question:
how to configure Qt on my ubuntu to build Qt binaries for my embedded linux
on arm? Do I need to include any libs build by the arm toolchain?
any help is appreciated!
regards
EDIT:
I use the -spec flag and pass the path to "mkspecs/qws/arm-linux-g++" where a "qmake.conf" is located. I did not change anything in here because I dont know wich qmake variable are relevant to link to my arm related libs.
So the right compiler is used, which I could verify when the make process starts. But I observed that in a config file called qconfig.h there is an ARCH flag which is set to i386 but I didnt figure out how one can configure this. I dont think I should manually edit this file.
EDIT2:
someone knows whats behind the file qconfig.h?? should I adjust it manually?
I will solve it by myself :)
After struggling a while and scanning the web I got a little deeper involved how everything works together. I did not understand how to generate an executable for my ARM target device. I figured out two things:
do not add your QT path for X11 at the beginning in your PATH variable. this might mess up your cross compilation.
edit the qmake.conf correspondingly. add your libs build for the target device which in my case are located within buildroot. Add theses lines to your qmake.conf file:
QMAKE_CFLAGS += -O3 -march=armv5te
QMAKE_CXXFLAGS += -O3 -march=armv5te
QMAKE_INCDIR_QT = /home/user/arm/toolchain/buildroot-2010.11/output/staging/usr/include
QMAKE_LIBDIR_QT = /home/user/arm/toolchain/buildroot-2010.11/output/staging/usr/lib
I got it running now. thanks to everyone!
Yes, either you provide the Qt libraries in your toolchain or you tell qmake where to find them. Also, I suspect you're calling qmake without the -spec parameters. If you are using the qmake you find in your distribution, it will use the default spec, which is not arm I guess. Add the -spec parameter and point it to the arm mkspec. Also, make sure the generated g++ commands link to the correct Qt libs compiled for arm.
You shall install QtSDK for embedded linux befor you use it to build your application. I'm afraid you just have QtSDK for x86 right now. After QtSDK for embedded linux installed, it has qws/linux-arm-g++ as the default mkspace typically. If you don't have QtSDK for embedded linux, you can build it from source. Then run qmake to create Makefile for you application.
$QTDIR_FOR_ARM/qmake
Reference:
Installing Qt for Embedded Linux and Cross-Compiling Qt for Embedded Linux Applications
Good day
Currently, I'm working on an embedded device based on arm-linux. I want to build GCC for my target architecture with Glibc. GCC builds successful, but I have trouble with Glibc build.
I use the latest version of Glibc (ftp.gnu.org/gnu/glibc/glibc-2.12.1.tar.gz) and port for them (ftp.gnu.org/gnu/glibc/glibc-ports-2.12.1.tar.gz)
my configuration line:
../../glibc-2.12.1/configure --host=arm-none-linux-gnueabi --prefix=/home/anatoly/Desktop/ARM/build/glibc-build --enable-add-ons --with-binutils=/home/anatoly/Desctop/ARM/toolchain/arm/bin/
configuration script work fine, but i get some compile error:
...
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/libmemusage_pic.a(memusage.os): In function me':
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/lmemusage.c:253: undefined reference to__eabi+read_tp'
...
I also tried using the old version (2.11, 2.10) but have the same error.
Does anybody know the solution for this problem?
Use a precompiled toolchain, like those provided by code sourcery.
If you want to make your own, optimised (premature optimization is the root of all evil), use crosstool-NG, which is a tool dedicated to cross-compilation toolchain building.
If you are not convinced, and want to do everything with your own hands, ask your question on the crosstool-NG mailing list.
Try substituting arm-linux-gnueabi for arm-none-linux-gnueabi. Check that a compiler, loader etc. with the prefix you used for "host" exist on your path.