Re: Specifying where Binutils is and what it is called

Re: Specifying where Binutils is and what it is called

[R. Diez]

> It looks like the simple solution is to just build and install
> binutils twice.  Once into temporary destination and once into
> final destination.  Then each compiler will be able to find binutils.
>  If you want to optimize this, you might be able to build binutils
> once, and install it twice, overriding prefix at install time to put it
> in the other install dir.

Finally good advice! Thanks!

That has worked. In case anybody is interested, the result is here:

https://github.com/rdiez/JtagDue/blob/master/Toolchain/Makefile

Search for INSTALL_GCC_PHASE_1_TO_SEPARATE_DIR in there for more information.

Best regards,
  rdiez

Re: Specifying where Binutils is and what it is called

[Christer Solskogen]

On 22.04.2020 14:24, R. Diez via Gcc-help wrote:
>> It looks like the simple solution is to just build and install
>> binutils twice.  Once into temporary destination and once into
>> final destination.  Then each compiler will be able to find binutils.
>>    If you want to optimize this, you might be able to build binutils
>> once, and install it twice, overriding prefix at install time to put it
>> in the other install dir.
> 
> Finally good advice! Thanks!
> 
> That has worked. In case anybody is interested, the result is here:
> 
> https://github.com/rdiez/JtagDue/blob/master/Toolchain/Makefile
> 
> Search for INSTALL_GCC_PHASE_1_TO_SEPARATE_DIR in there for more information.
> 
> Best regards,
>    rdiez
> 


I guess it would be a lot easier to create a combined source tree with 
gcc, binutils and newlib and to everything only once.

Download and unpack binutils,gcc,gmp,mpfr,mpc,isl(optional) and newlib.

$ cd gcc-*
$ ln -s ../gmp-* gmp
$ ln -s ../mpfr-* mpfr
$ ln -s ../mpc-* mpc
$ ln -s ../isl-* isl

$ for i in bfd binutils gas ld opcodes; do ln -s ../binutils-*/$i; done

for newlib
$ ln -s ../newlib-*/newlib
$ ln -s ../newlib-*/libgloss


$ mkdir ${HOME}/obj; cd ${HOME}/obj
$ (TARGET=m68k-elf && ${HOME}/src/gcc-*/configure --prefix=/${TARGET} 
--libexecdir=/${TARGET}/lib --target=${TARGET} --enable-languages=c,c++ 
--disable-libstdcxx-pch --with-newlib)

(optional: fix compiler flags)
sed -i 's/\-g /-pipe /' Makefile
sed -i '/^CFLAGS / s/$/ -march=native/' Makefile
sed -i '/^CXXFLAGS / s/$/ -march=native/' Makefile
sed -i '/^CFLAGS_FOR_BUILD/ s/$/ -march=native/' Makefile
sed -i '/^CXXFLAGS_FOR_BUILD/ s/$/ -march=native/' Makefile

Compile and install into staging area
$ make -j$(nproc)
$ make -j2 install-strip DESTDIR=$(pwd)/dest

(install-strip might fail for libgloss, so the workaround I've used is 
to do a "make install -j2" first, and a "make -j2 install-strip -k" 
aferwords)

-- 
chs

Re: Specifying where Binutils is and what it is called

[R. Diez]

> Maybe in the distant past of GCC there were some problems
> with this "combined build of GCC and newlib" but someone
> suggesting a separate build somewhere nowadays is really weird.

It's not that weird. Many people are using that method:

1) The OpenWrt build system does.

2) The ArchWiki describes that way too:
   https://wiki.archlinux.org/index.php/Cross-compiling_tools_package_guidelines
   Look for "stage 1" in that page.

3) crosstool-NG is specifically designed to build cross-compilers, and uses the same method:

   https://crosstool-ng.github.io/docs/toolchain-construction/
   Look for "core pass 1" in that page.


> [...]
> https://docs.rtems.org/releases/4.5.1-pre3/rtemsdoc/html/started/started00072.html

I would not trust the instructions on that page anymore. It's way too old.


> "To bring in newlib and libgloss, a user could link the newlib and
> libgloss subdirectories of the newlib source tree into the src tree of gcc."
> In :
> https://sourceware.org/newlib/faq.html

I would not trust the Newlib documentation very much. Building Newlib for a Linux system (as opposed to the usual embedded system) was broken for years, and it may still be. I would say the project is short on developers.

I did find some information in GCC's own Wiki:

https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc

But then it says "Create a tree that consists of all of the files from the GCC and binutils/gdb/newlib source trees (including several simulators in src/sim), with the GCC files overriding the binutils/gdb/newlib files when there's a conflict." Overwriting files like that doesn't exactly inspire confidence.

I have invested many hours of work to get a working, tailor-made cross-compiler for my embedded projects. I would even say "wasted a lot of time". I hope you understand that, before investing yet more work, I would like to see some modern, working example (makefile or script) first on how to build a GCC cross-compiler with Newlib in a single step.

Regards,
  rdiez

Re: Specifying where Binutils is and what it is called

[R. Diez]

> That seems like an unnecessary worry. Why would the
> phase 1 compiler install *more* than the final one?

That is a very bold claim to make. GCC is a complex beast. Are you sure about that? Is there any test case for it? How about in the future? What if only need the C compiler to build Newlib, but the final toolchain only needs the C++ compiler, in order to reduce the total toolchain build time and save space in my final container?

Installing the phase 1 GCC into a separate, temporary bin directory is a clean solution, and I think it is a reasonable goal to pursue.

In any case, I think the answers to the following questions are still interesting to know, as they may apply to other scenarios too:

1) Is there a way to convince GCC to find the Binutils with their full names (like arm-none-eabi-ar) in the PATH or with --with-build-time-tools=/some/dir , instead of just short names like "ar"?

2) Are --with-as and --with-ld always risky in this scenario, because of other tools like objdump, given that GCC's own documentation warns about an inconsistent set of Binutils?

Regards,
  rdiez

Re: Specifying where Binutils is and what it is called

[Jonathan Wakely]

On Mon, 20 Apr 2020 at 09:27, R. Diez wrote:
>
> > That seems like an unnecessary worry. Why would the
> > phase 1 compiler install *more* than the final one?
>
> That is a very bold claim to make. GCC is a complex beast. Are you sure about that? Is there any test case for it? How about in the future? What if only need the C compiler to build Newlib, but the final toolchain only needs the C++ compiler, in order to reduce the total toolchain build time and save space in my final container?

So delete the cc1 executable after installation. That's not hard.

Specifying where Binutils is and what it is called

[R. Diez]

Hi all:

I have been building cross-compiler toolchains for years with makefiles similar to this one:

https://github.com/rdiez/JtagDue/blob/master/Toolchain/Makefile

I have always been worried that installing GCC phase 2 on top of GCC phase 1 (with the same --prefix=/my/dir) may leave some undesired remnants behind. So I thought I should build and install GCC phase 1 somewhere else. After all, GCC phase 1 is not needed after the toolchain is complete.

The steps would look like this:

- Build and install Binutils with --prefix=/final/destination
- Build and install GCC phase 1 (minimal compiler) with --prefix=/temporary/destination
- Build and install Newlib with GCC phase 1 with --prefix=/final/destination
- Build and install GCC phase 2 with --prefix=/final/destination
- At this point, we could delete /temporary/destination

Unfortunately, I am having trouble with GCC phase 1 and Newlib:

a) If I configure GCC phase 1 with --prefix=/final/destination, it picks up the Binutils correctly.

The names it finds are arm-none-eabi-ar etc.

But that is not what I want after all.

b) If I configure GCC phase 1 with --prefix=/temporary/destination, it does not find arm-none-eabi-ar and the like, even if they are in the PATH.

It then picks up 'ar' for the host. Compilation fails later on with a message like this:

Assembler messages:
Fatal error: invalid -march= option: `armv7-m'

It took some time to build everything and to realise what the error cause was. I wish that GCC checked during the configuration phase that the found 'ar' etc. actually support the asked target architecture.

c) I can specify --with-build-time-tools=/some/dir , but then GCC does not pick full names like arm-none-eabi-ar . I have to specify a path like /home/rdiez/rdiez/arduino/toolchain-test-09-bin/arm-none-eabi/bin , which contains the same tools but with short names like "ar".

The trouble is, GCC needs then those 'ar' etc. tool on the path when building Newlib. Because 'ar' for the host has then the same name as 'ar' for the cross-compilation target, the host tools are not available anymore, which causes problems later on. I really need --with-build-time-tools to pick full names like "arm-none-eabi-ar".

d) I guess I could use --with-as and --with-ld to manually specify the right Binutils. The trouble is, there are other tools like objdump. GCC's own documentation warns about this:

"When you use this option, you should ensure that dir includes ar, as, ld, nm, ranlib and strip if necessary, and possibly objdump. Otherwise, GCC may use an inconsistent set of tools."

e) I could use the same --prefix for both GCC phase 1 and phase 2, delete the /final/destination when Newlib is complete, and reinstall to that /final/destination Binutils, Newlib and GCC phase 2. But that does not play well with Makefiles that are building in parallel. So I wish there is another way.

Can somebody help me with these issues?

Thanks in advance,
  rdiez

Re: Specifying where Binutils is and what it is called

[Jonathan Wakely]

On Sun, 19 Apr 2020 at 16:16, R. Diez via Gcc-help <gcc-help@gcc.gnu.org> wrote:
>
> Hi all:
>
> I have been building cross-compiler toolchains for years with makefiles similar to this one:
>
> https://github.com/rdiez/JtagDue/blob/master/Toolchain/Makefile
>
> I have always been worried that installing GCC phase 2 on top of GCC phase 1 (with the same --prefix=/my/dir) may leave some undesired remnants behind.

That seems like an unnecessary worry. Why would the phase 1 compiler
install *more* than the final one?

> So I thought I should build and install GCC phase 1 somewhere else. After all, GCC phase 1 is not needed after the toolchain is complete.
>
> The steps would look like this:
>
> - Build and install Binutils with --prefix=/final/destination
> - Build and install GCC phase 1 (minimal compiler) with --prefix=/temporary/destination
> - Build and install Newlib with GCC phase 1 with --prefix=/final/destination
> - Build and install GCC phase 2 with --prefix=/final/destination
> - At this point, we could delete /temporary/destination
>
> Unfortunately, I am having trouble with GCC phase 1 and Newlib:
>
> a) If I configure GCC phase 1 with --prefix=/final/destination, it picks up the Binutils correctly.
>
> The names it finds are arm-none-eabi-ar etc.

Right, that's how it should work.

> But that is not what I want after all.

Why not?

> b) If I configure GCC phase 1 with --prefix=/temporary/destination, it does not find arm-none-eabi-ar and the like, even if they are in the PATH.
>
> It then picks up 'ar' for the host. Compilation fails later on with a message like this:
>
> Assembler messages:
> Fatal error: invalid -march= option: `armv7-m'
>
> It took some time to build everything and to realise what the error cause was. I wish that GCC checked during the configuration phase that the found 'ar' etc. actually support the asked target architecture.
>
> c) I can specify --with-build-time-tools=/some/dir , but then GCC does not pick full names like arm-none-eabi-ar . I have to specify a path like /home/rdiez/rdiez/arduino/toolchain-test-09-bin/arm-none-eabi/bin , which contains the same tools but with short names like "ar".
>
> The trouble is, GCC needs then those 'ar' etc. tool on the path when building Newlib. Because 'ar' for the host has then the same name as 'ar' for the cross-compilation target, the host tools are not available anymore, which causes problems later on. I really need --with-build-time-tools to pick full names like "arm-none-eabi-ar".
>
> d) I guess I could use --with-as and --with-ld to manually specify the right Binutils. The trouble is, there are other tools like objdump. GCC's own documentation warns about this:
>
> "When you use this option, you should ensure that dir includes ar, as, ld, nm, ranlib and strip if necessary, and possibly objdump. Otherwise, GCC may use an inconsistent set of tools."
>
> e) I could use the same --prefix for both GCC phase 1 and phase 2, delete the /final/destination when Newlib is complete, and reinstall to that /final/destination Binutils, Newlib and GCC phase 2. But that does not play well with Makefiles that are building in parallel. So I wish there is another way.

Why bother with the deleting things step?

Re: Specifying where Binutils is and what it is called

[Kai Ruottu]

Jonathan Wakely via Gcc-help kirjoitti 19.4.2020 klo 21.49:

> On Sun, 19 Apr 2020 at 16:16, R. Diez via Gcc-help <gcc-help@gcc.gnu.org> wrote:
>> Hi all:
>>
>> I have been building cross-compiler toolchains for years with makefiles similar to this one:
>>
>> https://github.com/rdiez/JtagDue/blob/master/Toolchain/Makefile
>>
>> I have always been worried that installing GCC phase 2 on top of GCC phase 1 (with the same --prefix=/my/dir) may leave some undesired remnants behind.
> That seems like an unnecessary worry. Why would the phase 1 compiler
> install *more* than the final one?
>
>> So I thought I should build and install GCC phase 1 somewhere else. After all, GCC phase 1 is not needed after the toolchain is complete.
>>
>> The steps would look like this:
>>
>> - Build and install Binutils with --prefix=/final/destination
>> - Build and install GCC phase 1 (minimal compiler) with --prefix=/temporary/destination
>> - Build and install Newlib with GCC phase 1 with --prefix=/final/destination
>> - Build and install GCC phase 2 with --prefix=/final/destination
>> - At this point, we could delete /temporary/destination

Meanwhile one cannot build the standard C libraries for "system targets" 
(those which have the "native GCC" as the default) at the same
time with GCC, it is the assumption with the "embedded targets" using 
newlib (those which have the "cross GCC" as the default). Maybe
in the distant past of GCC there were some problems with this "combined 
build of GCC and newlib" but someone suggesting a separate
build somewhere nowadays is really weird. Already in the gcc-2.95 age 
the instructions were like this :

 1. Link the following directories from Newlib to the main GCC
    directory, /source/gcc-2.95.3/ :
      * ln -s ../newlib-1.8.2/newlib newlib
      * ln -s ../newlib-1.8.2/libgloss libgloss
 2. Change to the /build/gcc directory to configure the compiler:


        /source/gcc-2.95.3/configure \
             --verbose --target=m68k-rtems \
             --prefix=/gcc-m68k --with-gnu-as --with-gnu-ld \
             --with-newlib

In :
https://docs.rtems.org/releases/4.5.1-pre3/rtemsdoc/html/started/started00072.html

In the generic newlib build instructions this same thing should be seen.

Symlinking the 'newlib' and 'libgloss' subdirectories from the newlib 
sources into the GCC sources main directory is what should be
tried first and if doing that there are problems, they should be 
reported here or in other suitable places.

Re: Specifying where Binutils is and what it is called

[Kai Ruottu]

Kai Ruottu kirjoitti 20.4.2020 klo 8.25:

> In :
> https://docs.rtems.org/releases/4.5.1-pre3/rtemsdoc/html/started/started00072.html
>
> In the generic newlib build instructions this same thing should be seen.
>
I checked this and found :

"To bring in newlib and libgloss, a user could link the newlib and 
libgloss subdirectories of the newlib source tree into the src tree of gcc."

In :

https://sourceware.org/newlib/faq.html

Re: Specifying where Binutils is and what it is called

[Jim Wilson]

On Sun, Apr 19, 2020 at 8:14 AM R. Diez via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
> The steps would look like this:
> - Build and install Binutils with --prefix=/final/destination
> - Build and install GCC phase 1 (minimal compiler) with --prefix=/temporary/destination
> - Build and install Newlib with GCC phase 1 with --prefix=/final/destination
> - Build and install GCC phase 2 with --prefix=/final/destination
> - At this point, we could delete /temporary/destination

It looks like the simple solution is to just build and install
binutils twice.  Once into temporary destination and once into final
destination.  Then each compiler will be able to find binutils.  If
you want to optimize this, you might be able to build binutils once,
and install it twice, overriding prefix at install time to put it in
the other install dir.

Jim