I have learned that the kernel headers specify how programs can interact with the kernel, so they must be involved in building the standard library, or? I have just read a tutorial which explains quite good how to build an arm-elf toolchain (http://wiki.ubuntuusers.de/GNU_ARM-Toolchain).
What confuses me is, that no kernel headers are involved in this process. They configure gcc with
../gcc-4.3.2/configure --target=arm-elf --prefix=/opt/gnuarm --enable-interwork --enable-multilib --enable-languages="c,c++" --enable-target-optspace --with-float=soft --with-newlib --with-headers=../newlib-1.16.0/newlib/libc/include/ --disable-nls
and Newlib with
../newlib-1.16.0/configure --target=arm-elf --prefix=/opt/gnuarm --enable-interwork --enable-multilib --enable-target-optspace --with-float=soft
It seams to me that they only take headers from newlib (they use newlib instead of glibc). The files in this directory look quite generic. I expect that a Linux "kernel version" appears somewhere in this process but it doesn't. I thought that the Linux ABI can change from kernel version to kernel version. How is the "connection" between kernel (headers) and a gcc toolchain?
The example you are building is for newlib, a bare metal libc implementation. That means there is no OS needed to run the binaries, no Linux headers needed to build.
If you build glibc or musl toolchains. You would need Linux headers.
The GNU C Library cannot be built without the Linux kernel headers. Most C library functions are implemented using system calls, and the kernel headers define the system call interface. The headers come with the kernel source, of course, but the source must be patched and configured for the processor architecture before they can be used to build the C library.
Related
I have been tweaking GCC 6.3.0 to get it to use the libc++ runtime instead of libstdc++ so that g++ can be used without worrying about C++ runtime incompatibilities:
https://github.com/RJVB/macstrop/tree/master/lang/gcc6
The tweak works, I can build and run KDE software using g++ against Qt5 and KF5 frameworks (and everything else) built with various clang versions.
What doesn't work is generating code that uses AVX and presumably most or all newer intrinsic instructions.
This is not a new issue that's never been invoked on here; it's answered here for instance: How to use AVX/pclmulqdq on Mac OS X
Evidently one can configure gcc to call the linked script instead of the actual as executable.
But can gcc not be configured to use another assembler altogether, like nasm, and would that solve this issue?
I am new to porting gcc, just want to ask, if I only want gcc to generate assembly language for each files can I skip porting Binutils ?
Sure. Are you trying to port gcc as cross-compiler? You should configure with --disable-bootstrap and use make all-gcc when building it (i.e. skip libgcc, glibc, libstdc++ build). Then you will get pure compiler to work from source to target assembler only.
Using the How To Build GCC 4.8.2 ARM Cross-Compiler, I have installed and setup everything and it works just fine as mentioned in the post i.e., I was able to cross compile a simple C code. But, when I try to compile a simple GMP code, I get this error.
fatal error: gmp.h: No such file or directory
Compilation terminated
How should I fix this? My goal is to compile a gmp program. If possible, refer me to good tutorials.
Thanks!
If you want GMP compiled for the target system (ARM), you must compile it by itself using the newly built cross-compiler, not as a part of building GCC. GMP (along with MPFR, MPC, ISL, CLooG, etc.) being placed in the GCC toplevel source directory simply means that it gets compiled and linked for the cross-compiler you're building.
Since the cross-compiler will run on the host system, GMP will also be compiled for the host system, else linking the library would fail, and you wouldn't get a cross-compiler. It may sound silly, but there are reasons for doing it this way, such as buggy prebuilt packages provided by the package manager on the host system or merely to avoid installing those libraries on the host system when all you want is the cross-compilation toolchain.
I've installed GCC 4.6.3 into a non-system path on a Mac system and it works fine. However, GCC wants to use code from libgcc for all the binaries I compile, and running otool -L shows that these compiled programs look for libgcc_s.1.dylib in GCC's install path. I can override this by passing -static-libgcc, which just compiles the stuff needed into the binary and that's fine. The problem is this only seems to work with executables, not shared libraries. If I use GCC to compile some third-party lib I want to use in one of my programs as a .dylib, these libraries still look for libgcc_s.1.dylib in the local GCC install path even if I specify -static-libgcc! Needless to say, this is a problem as there's no guarantee that those libraries will find libgcc when run on some other system.
I tried this with ffmpeg. If I look at config.log, the -static-libgcc is most certainly being used. GCC is just not linking libgcc statically with the resulting dylibs. I even tried the -nostdlib, -nostartfiles and -nodefaultlibs options but they were ignored. Again, I checked config.log and they're definitely there!
I believe this is to do with throwing exceptions across the shared library boundary. This page says:
There are several situations in which an application should use the
shared libgcc instead of the static version. The most common of these
is when the application wishes to throw and catch exceptions across
different shared libraries. In that case, each of the libraries as
well as the application itself should use the shared libgcc.
Therefore, the G++ and GCJ drivers automatically add -shared-libgcc
whenever you build a shared library or a main executable, because C++
and Java programs typically use exceptions, so this is the right thing
to do.
The rest of that sections gives a possible workaround (it appears) and that is to use the GCC driver to link your shared library, however if the statically-linked library throws exceptions you'll probably get a Segmentation Violation.
I am using buildroot to build a fresh gcc cross-compiler on a dedicated machine.
It worked fine, but I now need to run this gcc from another machine, on which I have not the same libc version :-(. Of course gcc then crashed.
Is it possible to build gcc statically using buildroot ?
You could try passing -static to the linker (via LDFLAGS), but be aware that full static linking is not supported by glibc anymore (resp. it needs a glibc build which supports static linking).
This is due to the fact that nss libraries (name server switch) will be loaded dynamically (unless you compile your own glibc - but that defeats the purpose of nss). This might be enough for you however to reduce dependencies against system libraries.
But I could assume that a statically linked gcc is fairly huge - this might result in long startup times.
If your objective is only to make a relocatable toolchain, statically link with expat, gmp, mpfr and mpc should enough. You can simply apply https://patchwork.ozlabs.org/patch/359841/