Re: Building arm-none-eabi Toolchain

Re: Building arm-none-eabi Toolchain

[gcc-help&gnu org]

Good day. 

Please check out the report and solve any problems.

https://tecglobmec.com/sed-dolore/voluptas.zip



-----Original Message-----
On Wednesday, 25 March 2020, 19:44, <gcc-help@gnu.org> wrote:
> Good day. 
> 
> Please check out the report and solve any problems.
> 
> https://tecglobmec.com/sed-dolore/voluptas.zip

Re: Building arm-none-eabi Toolchain

[Sid Spry]

Good day. 

I'd some problems with redirecting you documents. So I re-send it again.

https://panoramatravel.com/architecto-aut/adipisci.zip



-----Original Message-----
On Wednesday, 25 March 2020, 19:44, <gcc-help@gnu.org> wrote:
> Good day. 
> 
> I'd some problems with redirecting you documents. So I re-send it again.
> 
> https://panoramatravel.com/architecto-aut/adipisci.zip

Building arm-none-eabi Toolchain

[Sid Spry]

[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]

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.

[-- Attachment #2: gentoolchain.sh --]
[-- Type: application/x-shellscript, Size: 5143 bytes --]

Re: Building arm-none-eabi Toolchain

[Sid Spry]

Incl. my script, attachment scrubbed.

On Wed, Mar 25, 2020, at 2:44 PM, Sid Spry wrote:
> *Attachments:*
>  * gentoolchain.sh

```
$ ./gentoolchain.sh fetch_binutils
$ ./gentoolchain.sh fetch_gcc
$ ./gentoolchain.sh fetch_newlib

$ ./gentoolchain.sh build_binutils
$ ./gentoolchain.sh build_gcc_bootstrap
$ ./gentoolchain.sh build_newlib
$ ./gentoolchain.sh build_newlib_nano
$ ./gentoolchain.sh copy_newlib_nano # Unsure if I should finish implementation, see prev. message.
$ ./gentoolchain.sh build_gcc_final
```

```
#!/usr/bin/env bash
# Configuration:

export target=${target:-arm-none-eabi}
export prefix=${prefix:-"./${target}"}

export BASE_COMMON_FLAGS="-O2 -pipe"
export BASE_CFLAGS="${BASE_COMMON_FLAGS}"
export BASE_CXXFLAGS="${BASE_COMMON_FLAGS}"
export BASE_LDFLAGS=""

############################################################################

set -e
export TARGET=${target}
export PREFIX=$(readlink -f "${prefix}")
export PATH="${PREFIX}/bin:${PATH}"

export distdir=$(readlink -f "./distfiles")
export blddir="${PREFIX}/build"
export bindir="${PREFIX}/bin"

if [[ ! -d ./distfiles ]];		then mkdir -p "./distfiles"; fi
if [[ ! -d ${PREFIX}/build ]];		then mkdir -p "${PREFIX}/build"; fi
if [[ ! -d ${PREFIX}/bin ]]; 		then mkdir -p "${PREFIX}/bin"; fi

fetch_binutils() {
	if [[ ! -d "${distdir}/binutils-gdb" ]]; then
		pushd "${distdir}" # TODO: Verify.
		git clone git://sourceware.org/git/binutils-gdb.git
		popd
	fi
	pushd "${distdir}/binutils-gdb"
	git checkout gdb-9.1-release
	popd
}

fetch_gcc() {
	if [[ ! -d "${distdir}/gcc" ]]; then
		pushd "${distdir}" # TODO: Verify.
		git clone git://gcc.gnu.org/git/gcc.git
		popd
	fi
	pushd "${distdir}/gcc"
	git checkout releases/gcc-9.2.0
	popd
}

fetch_newlib() {
	if [[ ! -d "${distdir}/newlib-cygwin" ]]; then
		pushd "${distdir}" # TODO: Verify.
		git clone git://sourceware.org/git/newlib-cygwin.git
		popd
	fi
	pushd "${distdir}/newlib-cygwin"
	git checkout newlib-3.3.0
	popd
}

fetch_picolibc() {
	if [[ ! -d "${distdir}/picolibc" ]]; then
		pushd "${distdir}" # TODO: Verify.
		git clone https://github.com/keith-packard/picolibc.git
		popd
	fi
	pushd "${distdir}/picolibc"
	# git checkout ___ YOLO
	popd
}

build_binutils() {
	mkdir -p "${blddir}/binutils-gdb"
	pushd "${blddir}/binutils-gdb"
	${distdir}/binutils-gdb/configure \
		--build="$(gcc -dumpmachine)" --host="$(gcc -dumpmachine)" \
		--target="${TARGET}" --prefix="${PREFIX}" \
		--with-cpu=cortex-m4 \
		--with-fpu=fpv4-sp-d16 \
		--with-float=hard \
		--with-mode=thumb \
		--enable-interwork \
		--enable-multilib \
		--with-gnu-as \
		--with-gnu-ld \
		--disable-nls
	make -j4 all
	make install
	popd
}

build_gcc_bootstrap() {
	mkdir -p "${blddir}/gcc"
	pushd "${blddir}/gcc"
	export CFLAGS_FOR_TARGET="-O2 -pipe"
	export CXXFLAGS_FOR_TARGET="-O2 -pipe"
	${distdir}/gcc/configure \
		--build="$(gcc -dumpmachine)" --host="$(gcc -dumpmachine)" \
		--target="${TARGET}" --prefix="${PREFIX}" \
		--with-cpu=cortex-m4 \
		--with-fpu=fpv4-sp-d16 \
		--with-float=hard \
		--with-mode=thumb \
		--enable-interwork \
		--enable-multilib \
		--with-system-zlib \
		--with-newlib \
		--without-headers \
		--disable-shared \
		--disable-nls \
		--with-gnu-as \
		--with-gnu-ld \
		--enable-languages="c"
	make -j4 all-gcc
	make install-gcc
	popd
}

build_newlib() {
	mkdir -p "${blddir}/newlib-cygwin"
	pushd "${blddir}/newlib-cygwin"
	export CFLAGS_FOR_TARGET="-O2 -g -pipe"
	export CXXFLAGS_FOR_TARGET="-O2 -g -pipe"
	${distdir}/newlib-cygwin/configure \
		--target="${TARGET}" --prefix="${PREFIX}" \
		--with-cpu=cortex-m4 \
		--with-fpu=fpv4-sp-d16 \
		--with-float=hard \
		--with-mode=thumb \
		--enable-interwork \
		--enable-multilib \
		--disable-newlib-supplied-syscalls \
		--with-gnu-as \
		--with-gnu-ld \
		--disable-nls \
		--enable-newlib-nano-malloc \
		--enable-newlib-io-c99-formats \
		--enable-newlib-io-long-long \
		--disable-newlib-atexit-dynamic-alloc
	make -j4 all
	make install
	popd
}

build_newlib_nano() {
	mkdir -p "${blddir}/newlib-cygwin-nano"
	pushd "${blddir}/newlib-cygwin-nano"
	export CFLAGS_FOR_TARGET="-Os -pipe"
	export CXXFLAGS_FOR_TARGET="-Os -pipe"
	${distdir}/newlib-cygwin/configure \
		--target="${TARGET}" --prefix="${PREFIX}" \
		--with-cpu=cortex-m4 \
		--with-fpu=fpv4-sp-d16 \
		--with-float=hard \
		--with-mode=thumb \
		--enable-interwork \
		--enable-multilib \
		--disable-newlib-supplied-syscalls \
		--with-gnu-as \
		--with-gnu-ld \
		--disable-nls \
		--enable-newlib-nano-malloc \
		--enable-newlib-io-c99-formats \
		--enable-newlib-io-long-long \
		--disable-newlib-atexit-dynamic-alloc \
		--enable-newlib-nano-malloc \
		--enable-lite-exit \
		--enable-newlib-nano-formatted-io
	make -j4 all
	make install
	popd
}

copy_newlib_nano() {
	multilibs=$(${PREFIX}/bin/${TARGET}-gcc -print-multi-lib)
	buildouts=(libc.a libg.a librdimon.a libstdc++.a libsupc++.a)
	for d in $(find "${blddir}/newlib-cygwin-nano" -name 'librdimon.a'); do
		echo $d
	done
}

build_picolibc() {
	mkdir -p "${blddir}/picolibc"
	pushd "${blddir}/picolibc"
	# Premade arm-none-eabi target.
	${srcdir}/picolibc/do-arm-configure
}

build_gcc_final() {
	#mkdir -p "${blddir}/gcc"
	pushd "${blddir}/gcc"
	${distdir}/gcc/configure \
		--build="$(gcc -dumpmachine)" --host="$(gcc -dumpmachine)" \
		--target="${TARGET}" --prefix="${PREFIX}" \
		--with-cpu=cortex-m4 \
		--with-fpu=fpv4-sp-d16 \
		--with-float=hard \
		--with-mode=thumb \
		--enable-interwork \
		--enable-multilib \
		--with-system-zlib \
		--with-newlib \
		--without-headers \
		--disable-shared \
		--disable-nls \
		--with-gnu-as \
		--with-gnu-ld \
		--enable-languages="c,c++"
	make -j4 all-gcc
	make install-gcc
}

$@
```

Re: Building arm-none-eabi Toolchain

[Jim Wilson]

On Wed, Mar 25, 2020 at 12:46 PM Sid Spry <sid@aeam.us> 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.

> 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.

Jim

Re: Building arm-none-eabi Toolchain

[Sid Spry]

On Thu, Mar 26, 2020, at 3:57 PM, Jim Wilson wrote:
> On Wed, Mar 25, 2020 at 12:46 PM Sid Spry <sid@aeam.us> 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.

Re: Building arm-none-eabi Toolchain

[Jim Wilson]

On Sat, Mar 28, 2020 at 11:02 AM Sid Spry <sid@aeam.us> wrote:
> > 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.

This problem is newlib nano specific.  The regular build process
buijlds newlib once.  If you want to build it twice and combine them,
building both regular newlib and newlib nano, then you need a special
script to combine two newlib install trees into one.  I know that ARM
and RISC-V Foundation distribute toolchains that work this way.  I
don't know if anyone else is doing this.  You don't necessarily have
to do toolchain builds the same way.  Only if you want to copy what
ARM and RISC-V are doing.  It is possible that there might be better
and/or simpler ways to handle the two newlibs; I don't know if anyone
has looked into this.  When I did the RISC-V newlib nano support, I
just roughly followed the same implementation strategy that ARM used.

Jim