I'm trying to build cross compiler for arm (target=arm-linux-gnueabihf)
from GCC 4.6 source code, with option -with-float=hard.
My compilation process fails on libgcc (unable to find /asm/errno.h file), I suppose I've used wrong sysroot
Configuration options:
--with-float=hard --with-mode=thumb --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-bootstrap --disable-libgomp --disable-libsanitizer --enable-bootstrap=no --target=arm-linux-gnueabihf --with-sysroot=$sysroot --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16
$sysroot it's local sysroot /usr/
host=linux-x86_64
Does any body know how to build arm hard float cross-compiler, based on gcc 4.6?
Building cross-compilers is trickier than you'd think. There's a circular dependency in which you can't build GCC without GLIBC, and you can't build GLIBC without GCC. The solution involves building the compiler three times, and GLIBC twice, each time with increasing number of features enabled, and is hard to explain.
If you have an existing sysroot then things are much easier. The cycle is broken, so it should just work, assuming the sysroot contains the header files as well as the binaries.
Except it's not that easy: things change over time, so an older compiler will struggle to find the files it needs in a newer sysroot (even though they're most likely present). You might be able to find an older sysroot from the 4.6 era, but chances are those will use the "softfp" ABI, so they won't work with your HF compiler.
I'd recommend using something like Crosstool-ng, which is a tool that tries to automate the process, and builds a working cross-compiler and library from source.
Related
I'm on a CentOS 7 Linux system where I don't have the root access. So I have to build gcc from source. I want to build gcc 11.2 with the jit support. I invoked
contrib/download_prerequisites for GMP, MPFR, MPC and ISL. Then from a build directory I configured gcc using
../gcc-11.2.0/configure --prefix=/some/path --enable-bootstrap --enable-shared \
--enable-host-shared --enable-threads=posix --enable-languages=c,c++,jit \
--disable-multilib
then I hit make.
It failed with ld errors asking me to recompile libisl.a, libmpc.a, libmpfr.a, libgmp.a with -fPIC. Right before these errors I saw lots of jit related outputs. I assume jit is behind all of this?
Then I tried adding CFLAGS=-fPIC to the above configure command as ../gcc-11.2.0/configure CFLAGS=-fPIC *rest_of_the_options_above*. The same ld errors were emitted.
I'm aware that those dependencies each has --with-pic option to their own configure. But I'm wondering if there is a way to have gcc invoke that for me? If not, does it mean that to build gcc with jit support, one has to build the four dependencies manually with --with-pic? Thanks.
I am building a custom kernel using Buildroot 2020.02.1 for a PC mounting a AMD GX-222GC SOC.
The default external toolchain is amd-2016.11-19 from CodeBench. Kernel built with that toolchain boots correctly.
Instead, if I build the same kernel, same configuration, with the toolchain automatically built by buildroot, the kernel doen not boot! Not even a kernel panic, machine just resets.
It is clear the problem is related to the toolchain.
These are the results of gcc -v
CodeBench:
$ output/host/usr/bin/x86_64-amd-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/media/AAA/tmp/buildroot_toolchain/output/host/opt/ext-toolchain/bin/x86_64-amd-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/media/AAA/tmp/buildroot_toolchain/output/host/opt/ext-toolchain/bin/../libexec/gcc/x86_64-amd-linux-gnu/6.2.0/lto-wrapper
Target: x86_64-amd-linux-gnu
Configured with: /scratch/jmyers/amd-lite/src/gcc-6-2016.11/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=x86_64-amd-linux-gnu --enable-threads --disable-libmudflap --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs --with-arch=btver2 --with-cpu=btver2 --with-gnu-as --with-gnu-ld --with-specs='-D__CS_SOURCERYGXX_MAJ__=2016 -D__CS_SOURCERYGXX_MIN__=11 -D__CS_SOURCERYGXX_REV__=19' --enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --with-glibc-version=2.24 --with-pkgversion='Sourcery CodeBench Lite 2016.11-19' --with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/x86_64-amd-linux-gnu/libc --with-build-sysroot=/scratch/jmyers/amd-lite/install/opt/codesourcery/x86_64-amd-linux-gnu/libc --with-gmp=/scratch/jmyers/amd-lite/obj/pkg-2016.11-19-x86_64-amd-linux-gnu/amd-2016.11-19-x86_64-amd-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr --with-mpfr=/scratch/jmyers/amd-lite/obj/pkg-2016.11-19-x86_64-amd-linux-gnu/amd-2016.11-19-x86_64-amd-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr --with-mpc=/scratch/jmyers/amd-lite/obj/pkg-2016.11-19-x86_64-amd-linux-gnu/amd-2016.11-19-x86_64-amd-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr --with-isl=/scratch/jmyers/amd-lite/obj/pkg-2016.11-19-x86_64-amd-linux-gnu/amd-2016.11-19-x86_64-amd-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr --enable-libgomp --enable-libitm --enable-libatomic --disable-libssp --disable-libcc1 --enable-poison-system-directories --with-python-dir=x86_64-amd-linux-gnu/share/gdb/python --with-build-time-tools=/scratch/jmyers/amd-lite/install/opt/codesourcery/x86_64-amd-linux-gnu/bin --with-build-time-tools=/scratch/jmyers/amd-lite/install/opt/codesourcery/x86_64-amd-linux-gnu/bin SED=sed
Thread model: posix
gcc version 6.2.0 (Sourcery CodeBench Lite 2016.11-19)
Buildroot:
Using built-in specs.
COLLECT_GCC=/media/AAA/tmp/buildroot_toolchain/output/host/opt/ext-toolchain/bin/x86_64-linux-gcc.br_real
COLLECT_LTO_WRAPPER=/media/AAA/tmp/buildroot_toolchain/output/host/opt/ext-toolchain/bin/../libexec/gcc/x86_64-buildroot-linux-gnu/7.5.0/lto-wrapper
Target: x86_64-buildroot-linux-gnu
Configured with: ./configure --prefix=/media/AAA/tmp/buildroot_toolchain/output/host --sysconfdir=/media/AAA/tmp/buildroot_toolchain/output/host/etc --enable-static --target=x86_64-buildroot-linux-gnu --with-sysroot=/media/AAA/tmp/buildroot_toolchain/output/host/x86_64-buildroot-linux-gnu/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --with-gmp=/media/AAA/tmp/buildroot_toolchain/output/host --with-mpc=/media/AAA/tmp/buildroot_toolchain/output/host --with-mpfr=/media/AAA/tmp/buildroot_toolchain/output/host --with-pkgversion='Buildroot 2020.02.1-00007-g345f377da1-dirty' --with-bugurl=http://bugs.buildroot.net/ --enable-libquadmath --enable-tls --enable-threads --without-isl --without-cloog --with-arch=btver2 --enable-languages=c,c++ --with-build-time-tools=/media/AAA/tmp/buildroot_toolchain/output/host/x86_64-buildroot-linux-gnu/bin --enable-shared --disable-libgomp
Thread model: posix
gcc version 7.5.0 (Buildroot 2020.02.1-00007-g345f377da1-dirty)
Do you see some options that might be required for gcc and buildroot toolchain is missing?
Thanks in advance.
PS: I even tried gcc 8 without resolving.
The early 4.4.x kernels do not boot when built with binutils >= 2.31. This was fixed in commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=073bb7ddd35ca8f17a170258dacbe384935a43c8 in the 4.4.x stable branch, which was merged in 4.4.124. So any 4.4.x earlier than that, when built with binutils >= 2.31, will not boot.
I used to use MSVC a lot, and now I want to try out new C++17 features, so I decided to use mingw-w64 toolchian.
Btw I'm new to building things from source
I also want the ability to compile both 32 bit and 64 bit application (multilib).
I had mingw-w64 headers installed, then I tried to bootstrap GCC 7.1.0 in MSYS2.
I configured it by this command
../src/configure --enable-languages=c,c++ --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --enable-targets=all --disable-werror --prefix=/c/tmp/gcc/dest --with-sysroot=/c/tmp/gcc/dest --disable-shared --disable-win32-registry --enable-version-specific-runtime-libs
The process completed without an error, however the compiler isn't usable.
I tried to compile a file a.cpp by
g++ -o a.exe a.cpp
Unfortunately, a message box with title cc1plus appeared saying The code execution cannot proceed because libgcc_s_seh-1.dll was not found.
Reinstalling the program may fix this problem.
That suggested that I should have libgcc, but how can I get it?
I configured gcc as follows:
../configure
--prefix=/c/mbuild/release --enable-shared=libstdc++ --enable-threads --enable-version-specific-runtime-libs --enable-languages=c,c++ --with-dwarf2 --disable-sjlj-exceptions --disable-win32-registry --disable-werror --disable-nls --disable-multilib --with-gmp=/c/mbuild/release --with-ppl=/c/mbuild/release --disable-ppl-version-check --with-cloog=/c/mbuild/release --disable-cloog-version-check --with-mpfr=/c/mbuild/release --with-mpc=/c/mbuild/release --enable-libgomp --with-libiconv-prefix=/c/mbuild/release
--enable-libstdcxx-debug --enable-cxx-flags='-s -O2' *--with-boot-ldflags='-s'* --with-boot-cflags='-s -O2' --with-boot-cxxflags='-s -O2' &>config.my.log
and build:
make -j4 BOOT_CFLAGS='-s -O2'
BOOT_CPPFLAGS='-s -O2' &>make.my.log
I've got everything optimized, except libstdc++-6.dll. It size is 5Mb!
So... What options should i use during gcc (mingw) configuration to build libstdc++.dll without debugging information?
NOTE:
I need debug and release versions of libstdc++, so I'm using
--enable-libstdcxx-debug - Build separate debug libraries in addition to what is normally built.
This flag makes another libstdc++-6.dll (somwhere in lib dir), wich is larger, than dll in the bin dir.
You should pass strip option to linker, not to compiler (-s). And to compiler you should pass "-g -O0" for debug build, which means include debug information + stright code generation without any optimization (the last one is for case you read disasm code, it makes stuff clearer). So, try adding to LDFLAGS environment variable -s option for build time.
As an alternative, you could use "strip" program (part of MSYS) to strip all debug info from executable and/or library binary file.
I was thinking about using ccache with gcc compiled code on the team wide base (same ccache's cache will be used by all developers on the same machine).
Since we're talking about commercial product, "correctness" of compilation is a top priority.
Here come questions:
Is the compilation using ccache is safe/reproducible?
Is there some exception situations that ccache supposes cache hit mistakenly.
If I checkout a source code and compile it, I expect to receive the same products
(exactly same libraries/binaries) each time I repeat a fresh compilation process.
This is must to for commercial product.
Is there're open source/commercial products using ccache an integral part of their
build system? This will make it easier to convince my colleagues to use ccache.
Thanks
According to its manual, ccache determines whether it has compiled some object before on the following:
the pre-processor output from running the compiler with -E
the command line options
the real compilers size and modification time
any stderr output generated by the compiler
If some PHB is still worried about any assumed risk you take because of ccache, only use it for development builds and build the final product using the compiler without any front-end. Or you could clear the cache before building the final product.
Update: I don't know about products using ccache as an integral part of their build system, but it is really trivial to integrate into any environment where you can set the compiler's path. I.e. for autoconf:
CC="ccache gcc" ./configure
And after looking at the author's name, I'd say it's a pretty safe assumption that it has been widely used within the Samba team.
Update in response to Ringding's comment about usage of stderr: From ccache's point of view, one interesting bit of information is the C compiler's version and configuration string. gcc outputs that to the standard error file:
$ gcc -v 2>err
$ cat err
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-2' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-2)
I'd bet that ccache uses this or a similar output. But, hey, you can always look at its source code. :-)
I am personally familiar only with ccache which is very simple to use, and I find it extremely useful for my large scale private projects.
However, as for a team wide base, I have no experience yet.
You may be interested also in AO (audited objects):
In general:
it provides a more robust mechanism, can use distributed environment for caching
ccache speed up only compilation time, while AO speed up link time too.
not limited only to c/c++
Not long after my posted answer (1.5 years ago...), I managed to convince our build and R&D managers, to integrate ccache into the automatic build system, and they are grateful to me on that. The company employs more than 200 developers, so it is really working. As for the linking phase, it is still an issue.