@StephenWarren, in #11, you mentioned using gcc 4.5.3 (the tool used to build tools can have an effect, but I’m mentioning this because it differs from the git repo numbering). I consider it possible (considering the the age of crosstool-ng and gcc 4.5.3) that this suggests building crosstool-ng with a native x86/x86_64 gcc 4.5.3 (whereas most hosts now have a gcc 7.x or above, although that will probably work). Alternatively, this could mean that the crosstool-ng source was compiled and produced gcc 4.5.3. I just want to clarify that https://github.com/crosstool-ng/crosstool-ng/releases, which defaults to release version crosstool-ng-1.24.0 (if another tag is not stated), and is the correct source for the build. Perhaps an older crosstool release from around 2011 would be more appropriate? I don’t know.
@michaelwei9pt6c, as mentioned by @StephenWarren, the cross linker architecture is wrong (a cross tool was being created, but it was being created to run on Alphav4 to produce armhf instead of being built to run on x86/x86_64 to produce armhf). Keep in mind that when building cross tools you must specify both the architecture the tools will run on (x86/x86_64 if you have a PC), and the architecture you are going to produce by the tool. If one tool is required to build another tool, then you may need to build a series of tools. Examples:
- Build PC tool from a PC -> produces armhf code.
- Build Alphav4 tool from a PC -> produces armhf, but won't run on a PC.
- Build Alphav4 tool from a PC requiring intermediate tool -> produces Alphav4 tool running on PC which in turn builds a purely Alphav4 tool to output armhf.
This latter “triple architecture” configuration case is needed if your configuration needs an intermediate tool to build the final tool. There is an extra architecture beyond x86/x86_64 and armhf: Alphav4, intended to be an intermediate host architecture (not what you want). Typical case: Configuration defaulted to something you didn’t intend.
Incidentally, there is a full instruction page here (and configuring cross tools for build is generally not an easy or simple thing, so it is worth looking at):
http://crosstool-ng.github.io/docs/
Caveat for what I see during a compile: I am using Fedora with gcc-7.3.1. No doubt there will be differences on Ubuntu 18.04.
NOTE: Build configuration usually produces multiple tools (emphasis plural), needed for both bare metal (static, e.g., bootloader or kernel) and user space (linked) applications, and sometimes one tool uses the other. If your build were only for a compiler with bare metal, then there would be no need for a linker. When the tools are built together as a set, then one tool might need to call another. The docs URL above will talk about configuring, and since you might (incorrectly, by accident) be building the tool to execute on a different architecture (neither armhf nor x86/x86_64, but instead DEC Alpha v4 minicomputer/mainframe…you want to execute on x86/x86_64), and that different architecture will output yet another architecture (armhf, regardless of execution on x86/x86_64 or Alphav4), then it is likely you need to reconfigure for just two architectures: Native x86_64/x86, foreign armhf. Skip Alphav4 (old DEC computer) through configuration.
Notice that if you download the git repo, then you will have a subdirectory:
crosstool-ng/testing/docker/
…and if you are using Ubuntu 18.04:
crosstool-ng/testing/docker/ubuntu18.04/
Within that directory is file “Dockerfile”. You will see some apt-get lines, and some packages needed for build. As individual commands this is:
sudo apt-get update
sudo apt-get install <b>-y</b> gcc g++ gperf bison flex texinfo help2man make libncurses5-dev \
python3-dev autoconf automake libtool libtool-bin gawk wget bzip2 xz-utils unzip \
patch libstdc++6
(perhaps you already have these…remove the “-y” if you want to manually confirm any installs)
I do not run in a container environment, and some of this is for doing so…but the actual packages needed in the apt-get command will not care if this is a container or a native Ubuntu 18.04. I am only using the Dockerfile as a list of needed packages.
The toplevel crosstool-ng directory will contain file “bootstrap”. As a regular user I ran this (“./bootstrap”). This creates some configuration files among which options can be picked. The “configure” file is a result of this, and is the main method of configuring.
Running “./configure --help” to see options helps. I always manually select “–prefix”. For my case:
./configure --prefix=/usr/local/crosstool-ng/git_1.24.0
(my user has created “/usr/local/crosstool-ng/git_1.24.0/”, and has permission to read/write there)
When I run “make” and then “sudo make install”, I get the configure utility:
/usr/local/crosstool-ng/git_1.24.0/bin/ct-ng
(this is used for other configuration steps)
I then make this available in my user’s path (and you’ll need to do this for root as well if you use sudo):
export PATH="${PATH}:/usr/local/crosstool-ng/git_1.24.0/bin"
(note that “/usr/local/crosstool-ng/git_1.24.0/bin” is my prefix plus “/bin/”)
From the top level of the source tree (this is the main key you need to fix most everything in the build):
ct-ng menuconfig
(note the “Help” menu at the bottom)
It is in “Target options —>” where the current config issue is fixed. The default, if you go in to that, is “Target Architecture (alpha) —>”. This needs to be “arm” (32-bit ARMv7-a). Within this you will need to add things like thumb “interworking”, switching back and forth between modes can be useful. All ARMv8 32-bit superset architectures support thumb, although you might not use it. EABI is already correctly set. Everything done in any ARM you might see from NVIDIA, going back a very long time, uses EABI. 32-bit little endian is correct.
Target OS can remain “bare-metal” since you are working on a bootloader. If you were to use “linux”, then possibly this would require a cross linker you don’t want to build.
Note that the “.config” will update if you exit the menuconfig, and that if you start menuconfig again, then it will start where you left off. If you find something you want to remember, then guard a copy of the “.config”.
I did not actually complete my build since it then had an issue with not finding “-lstc++” (which I am guessing might be needing 32-bit x86 instead of 64-bit x86_64…not sure). However, this would get you started and get past the alphav4 incorrect architecture.