On Thu, Mar 26, 2020, at 3:57 PM, Jim Wilson wrote: > On Wed, Mar 25, 2020 at 12:46 PM Sid Spry <sid@xxxxxxx> wrote: > > 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: > > This uses --with-multilib-list=rmprofile which gives a large multilib > list for cortext r and m parts. It appears that you aren't using > this, and hence getting the default multilib list which is smaller. > Thank you immensely, I kept overlooking this as I read through the script. > > 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? > > This is not part of the standard build process, and you need to do > this manually in your build script. You are building newlib twice, > and then renaming files so you can combine two newlib builds into one > newlib install tree. > So, not entirely directed at you, but the next sentence is -- for how many targets do there exists these instructions which are not part of the main source tree? My next goal is to build for the RISC-V targets. I'd like to encapsulate any configuration into modules of the script I am making. What is configurable, and is this written down? Some fair bit of it does seem to be in the ./configure help output, but then some of it isn't. There is an extant project, crossdev (https://wiki.gentoo.org/wiki/Crossdev), which unfortunately has routine breakage due to a failure to account for changes in how GCC is built and toolchain configuration is managed. R0b0t1.
