I am trying to build a cross compiler for PowerPC e500mc with target powerpc-e500mc-eabi. As some websites mentioned, i built an bootstrap compiler first. and then tried to compile newlib with it. But i got some error like,
/bin/sh: powerpc-e500mc-eabi-cc: command not found
I want to know, can we directly compile GCC cross compiler without newLib. Also, can anyone tell me the exact pre-requisites for powerpc e500mc architecture. I have GMP, MPC, MPFR, BinUtils not sure whether newLib required or not.
You can build gcc without any C library, there is no need for newlib. Please find a list of dependencies from a crosstool-ng build below.
1. Alternatives
You can build everything manually, what you obviously attempted to do. This is possible but there are various constraints to keep in mind, for instance builds might fail if your filesystem is not case sensitive or if you build inside your source directory. Besides all the dependencies and their versions.
You let crosstool-ng build your cross toolchain. Crosstool-ng is mostly self-contained with few external dependencies. It will download and build all dependencies in the right versions for you, and it comes with various sample configurations. It will check for obstacles like a case insensitive filesystem. It lets you configure your cross toolchain in a similar way you configure a Linux kernel. I've built various cross toolchains by means of it for several years on several host systems without trouble, including Linux, OS X (homebrew) and Windows (cygwin). You find it here: http://crosstool-ng.org/.
I'm going to line out the steps that it takes to build a cross toolchain by means of crosstool-ng. I tested this setup on Windows (cygwin) today with the crosstool-ng from git.
2. Download crosstool-ng, build and install it.
Follow the steps in
docs/2 - Installing crosstool-NG.txt.
3. Configure your cross toolchain.
Follow the steps in
docs/3 - Configuring a toolchain.txt.
4. Example
mkdir powerpc-e500v2-eabi
cd powerpc-e500v2-eabi
ct-ng powerpc-e500v2-linux-gnuspe
The last step will create a configuration from a sample which I thought is similar enough to what you want. In the next step, we will adapt this configuration, the criteria are
no operating system
no C library
EABI
you want e500mc, the sample is e500v2. I leave it up to you to adapt the configuration to it.
4.1. Configuration
ct-ng menuconfig
Operating System
Target OS
Select bare-metal
C-library
C library
Select none
Target options
ABI
Select EABI
C-Compiler
gcc version
Select 5.1.0 (the sample configured a gcc 4.6.4
here)
Deselect C++ (since you do not want a C library
either and it'd pull extra dependencies)
Debug facilities
Deselect gdb (unless you want it, can pull extra dependencies)
4.2. Build
ct-ng build.4
Crosstool-ng will download and build the following dependencies.
gmp-6.0.0a
mpfr-3.1.2
isl-0.14
mpc-1.0.2
binutils-2.25
gcc-5.1.0
It will install the cross toolchain in
${HOME}/x-tools/powerpc-e500v2-eabi.
You can specify a different install prefix in the configuration.
This build issue can be fixed by creating a symlink powerpc-e500mc-eabi-cc pointing to powerpc-e500mc-eabi-gcc.
Related
I'm looking for a cross compiler to compile for linux under the msys2 environment.
I'm looking for somethink like x86_64-w64-linux-gcc. But I can't find it.
Which package I have to install?
You'll need a VM or a Linux machine to test the resulting binaries, so I'd just compile on one in the first place.
But cross-compilation should be possible too:
Boot up your favorite Linux distribution in a VM.
Install the libraries you want to have. Install g++ to get libstdc++, and possibly other basic libraries.
Copy the root directory / from the VM to the Windows machine.
You only need headers and libraries, not everything. You'll have to experiment to know what directories can or can't be safely removed.
Install Clang on the Windows machine. Installing LLD is also a good idea (it's a separate package in MSYS2; or, if you're using the official Clang binaries, it's bundled with them).
We're using Clang, because it's inherently a cross-compiler, i.e. doesn't require separate binaries to target a different platform, unlike GCC.
Compile with Clang with --target=x86_64-pc-linux-gnu --sysroot=path/to/root/directory.
-fuse-ld=lld is probably a good idea as well.
The string x86_64-pc-linux-gnu was obtained by running clang++ --version on a Linux machine.
You might need a few more flags, but this should be a good starting point.
My developing/producing environments are all CentOS-7.7.
In order to compile my program with gcc-8.3.0, I have installed "devtoolset-8" on my developing env, but it can not be used in the way same as gcc-4.8.5 that was shipped with CentOS7 oringinally.
Every time I need to compile a program, I must use "scl enable devtoolset-8 -- bash" to switch to gcc8 instead of gcc4.8.5.
When the program was deploying onto the producing-env, there is no gcc8, nor libstdc++.so.6.0.25, so it can not run.
I guess libstdc++.so.6.0.25 should be released with gcc8? I can neither install "devtoolset-8" on the producing-env, nor build gcc8 from source on the producing env.
The version of libstdc++ that can be installed from the official yum repo of CentOS, is libstdc++.so.6.0.19, hence my programs can not be loaded at the producing-env.
How to let such programs to run?
Thanks!
Pls forgive my Ugly English.
In order to not have to copy or ship a separate libstdc++.so but rather link statically (as suggested in a comment) against the C++ runtime, one can link C++ programs with -static-libstdc++ (also specifying -static-libgcc will also make sure that the program does not depend on a recent enough version of libgcc_s.so on the system - although that should rarely be a problem).
There can also be the issue of the target system having a version of glibc that is too old (relative to the build system). In that case, one could anyhow compile gcc of no matter how recent of a version on the older system, so that the resulting C++ executables as well as libstdc++ are linked against the older glibc. Linking C++ programs with -static-libstdc++ will again help to not depend on the program having to be able to find libstdc++.so at run-time.
Finally, the C++ program could also be linked with -static not depending on any dynamic libraries at all.
I am trying to update our cross compiler toolchain from crosstool to crosstool-ng. We are using an old kernel and build machine. I could install and configure crosstool-ng-1.0.0 on the server and build the toolchain.
One difference that I have noticed between the output of crosstool and crosstool-ng is that the crosstool-ng is missing some of library under output folder. For example libcrypt.a, libdl.a, libnss_dns.so, libpthread.so and so on.
I have noticed that while building with crosstool we are setting KERNELCONFIG to a specific kernel configuration file. In that configuration file we have configurations like:
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=ycryp
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=y
Is this the reason that libraries like libcrypt are missing. In that case is there a way to set KERNELCONFIG in crosstool-ng for example as a build parameter?
All the libraries you mention are part of glibc, and the glibc build does not depend on the kernel configuration at all. You should check if you have enabled building glibc at all.
I managed to build a cross gcc-7.2.0 with multilib support for several Cortex-M-Targets with and without hard and soft floating point according to the processor capabilities.
Now, after final install step (make install), I find only one libstc++.a in the installation directory. For the other C++ libraries I see the same problem.
I expected one in every multilib subdirectory, the same way as I can find libc, libm and the like. But there are no libstdc++.a in the multilib subdirectories.
I think, this is not right.
Linking my test project failes with
libstdc++.a(atexit_arm.o) uses VFP register arguments, ../target.elf does not.
This suggests problems with the multilib installation.
How can I fix this multilib problem in the build phase?
After I added some configuration options to the configure call of binutils and GCC, the multilib configuration is working like a charm now.
For binutils I added --enable-version-specific-runtime-libs.
For GCC I added --enable-multiarch --enable-version-specific-runtime-libs.
Don't know, if the multiarch option is really necessary for my problem, but I didn't investigate further and I leave the information here.
I build a cross compile toolchain on OSX with:
binutils-2.23.52
gcc-4.6.4
gcc-core-4.6.4
gcc-g++-4.6.4
gdb-7.6.1
gmp-4.3.2
mpc-1.0.1
mpfr-2.4.2
newlib-2.0.0
for the target EFM32 wich is a ARM Cortex-m3, so the gcc target is arm-none-eabi.
All compiled fine.
But making programs with this toolchain like blink.c don't actually run on the EFM32 board.
I checked the blink.bin I did with a binary created with a IAR commercial toolchain delivered in the demos from energymicro, also gcc based and the they look very different internally (as expected :).
So has my toolchain wrong libs/versions or is it simply a matter of gcc/ld/ar switches wrong and what would be the steps to systematicly analyse this?