Building arm-none-eabi Toolchain

[Sid Spry]

Hello, I'm trying to understand the build process. I am comparing my script to one produced by Freddy Chopin. Additional goals of my script are the eventual ability to track the provenance of the releases used to produce the toolchain.

Original script is here: https://github.com/FreddieChopin/bleeding-edge-toolchain/blob/master/build-bleeding-edge-toolchain.sh. It is fairly straightforward. What I am running into now, is that when producing gcc and newlib-cygwin-nano, I do not generate all expected targets:

My build.
```
% find . -name 'librdimon.a'
[...]
./arm-none-eabi/build/newlib-cygwin-nano/arm-none-eabi/libgloss/arm/librdimon.a
./arm-none-eabi/build/newlib-cygwin-nano/arm-none-eabi/thumb/libgloss/arm/librdimon.a
./arm-none-eabi/build/newlib-cygwin-nano/arm-none-eabi/thumb/autofp/v7/fpu/libgloss/arm/librdimon.a
./arm-none-eabi/build/newlib-cygwin-nano/arm-none-eabi/arm/autofp/v5te/fpu/libgloss/arm/librdimon.a
[...]
```

Chopin's build.
```
% find . -name 'librdimon.a'
./installNative/arm-none-eabi/lib/arm/v5te/softfp/librdimon.a
./installNative/arm-none-eabi/lib/arm/v5te/hard/librdimon.a
./installNative/arm-none-eabi/lib/thumb/nofp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7/nofp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7+fp/softfp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7+fp/hard/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7-r+fp.sp/softfp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7-r+fp.sp/hard/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v6-m/nofp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7-m/nofp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7e-m/nofp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7e-m+fp/softfp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7e-m+fp/hard/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7e-m+dp/softfp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v7e-m+dp/hard/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v8-m.base/nofp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v8-m.main/nofp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v8-m.main+fp/softfp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v8-m.main+fp/hard/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v8-m.main+dp/softfp/librdimon.a
./installNative/arm-none-eabi/lib/thumb/v8-m.main+dp/hard/librdimon.a
./installNative/arm-none-eabi/lib/librdimon.a
```

Searching for librdimon.a was done as it is produced for the C++ target. Are the actions undertaken in `copyNanoLibraries` (https://github.com/FreddieChopin/bleeding-edge-toolchain/blob/master/build-bleeding-edge-toolchain.sh#L584) not part of the build process elsewhere?

A number of years ago I began trying to do this same thing and received information indicating that building libmpfr, etc, as done in `build-bleeding-edge-toolchain.sh` is not the modern method. I seem to have pieced together a method that works but can anyone verify that?

R030t1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gentoolchain.sh
Type: application/x-shellscript
Size: 5143 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20200325/0e7e1c5a/attachment.bin>