Re: Error building gcc 4.5.2 for AVR

Re: Error building gcc 4.5.2 for AVR

[Kai Ruottu]

25.1.2011 1:57, Jonathan Wakely kirjoitti:

> On 24 January 2011 22:49, Omar Choudary wrote:
>>
>> I am creating a script for building GCC 4.5.2 for the AVR target:
>> http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh
>>
>> I have some troubles when building GCC-4.5.2, see below, maybe you can
>> help me; thanks:
>
> This question is off-topic on this mailing list, please send such
> questions to the gcc-help@gcc.gnu.org list, as described
> http://gcc.gnu.org/lists.html
>
> Since you're using a third-party's build script, not the GCC
> installation instructions, you might be able to ask the author of that
> script for support.

The asker here seems to be the "supporter" :(

Generally the AVR case seems to be a special case. The gcc-4.5.2
configury system gives the complete target name :

[root@localhost gcc-4.5.2]# ./config.sub avr
avr-unknown-none

for the bare "avr" target name used by Omar. The plain vanilla
gcc-4.5.2 configury recognizes this as the second of the two
following templates :

avr-*-rtems*)
         tm_file="avr/avr.h dbxelf.h avr/rtems.h rtems.h newlib-stdint.h"
         tmake_file="avr/t-avr t-rtems avr/t-rtems"
         extra_gcc_objs="driver-avr.o avr-devices.o"
         extra_objs="avr-devices.o"
         ;;
avr-*-*)
         tm_file="avr/avr.h dbxelf.h newlib-stdint.h"
         use_gcc_stdint=wrap
         extra_gcc_objs="driver-avr.o avr-devices.o"
         extra_objs="avr-devices.o"
         ;;

ie. probably as a "plain vanilla newlib-based embedded target". So,
what a totally dummy GCC builder would expect the AVR target to use
is :

1. it uses ELF as its object format

2. it uses newlib as its target C library

just like many others targets met earlier...

So this dummy GCC builder is expected to try to build one's toolchain
using the (should be) well-known '*-elf' embedded target toolchain
build process via configuring something like :

   .../configure --prefix=<something> --target=avr-elf --with-newlib

and probably "succeeds" nicely when writing 'make'... Before becoming
aware that newlib really doesn't support AVR :( and there are more
"specific" notes for this "special" target in :

http://gcc.gnu.org/install/specific.html#avr

I tried this "dummy builder from the street" approach and getting
the toolchain succeeded nicely with the plain vanilla gcc-4.5.2
sources, no errors ever :

[root@localhost build]# cd gcc
[root@localhost gcc]# ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: avr-elf
Configured with: ../configure --build=i686-linux-gnu 
--host=i686-linux-gnu --target=avr-elf --enable-languages=c,c++ 
--with-newlib --disable-shared --disable-threads --disable-nls 
--with-gxx-include-dir=/usr/local/include/c++/4.5.2 
--enable-version-specific-runtime-libs --with-pkgversion='by Kai Ruottu 
2011q1'
Thread model: single
gcc version 4.5.2 (by Kai Ruottu 2011q1)

 >> make[2]: Leaving directory
 >> `/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty'
 >> /bin/bash: line 3: cd: avr/libgcc: No such file or directory
 >> make[1]: *** [install-target-libgcc] Error 1

If Omar really tries to support the GCC for AVR builders, one dummy
question is : "Why the expected '--with-newlib' is not used in his
GCC configure ?  This definitely is the option which defines the
case being "a generic embedded target case" and removes all kind of
checks and link tests with the "expected to exist prebuilt target C
library", which is the default for "a generic system target case".
The equation: "embedded" == "use the '--with-newlib'" should be known
quite well, at least what leaving it away would mean during the GCC
build...

Re: Error building gcc 4.5.2 for AVR

[Jonathan Wakely]

On 25 January 2011 10:25, Kai Ruottu wrote:
> 25.1.2011 1:57, Jonathan Wakely kirjoitti:
>
>> On 24 January 2011 22:49, Omar Choudary wrote:
>>>
>>> I am creating a script for building GCC 4.5.2 for the AVR target:
>>> http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh
>>>
>>> I have some troubles when building GCC-4.5.2, see below, maybe you can
>>> help me; thanks:
>>
>> This question is off-topic on this mailing list, please send such
>> questions to the gcc-help@gcc.gnu.org list, as described
>> http://gcc.gnu.org/lists.html
>>
>> Since you're using a third-party's build script, not the GCC
>> installation instructions, you might be able to ask the author of that
>> script for support.
>
> The asker here seems to be the "supporter" :(

Oops! Sorry, I didn't notice that.

Error building gcc 4.5.2 for AVR

[Omar Choudary]

Hello,

I am trying to build GCC 4.5.2 for the AVR target. See my script:
http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh

I have some troubles when building, see below, maybe you can
help me; thanks:

...
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty/testsuite'
/bin/bash ../../libiberty/../mkinstalldirs /usr/local/avr/lib/`gcc -g
-O2 -print-multi-os-directory`
/usr/bin/install -c -m 644 ./libiberty.a /usr/local/avr/lib/`gcc -g
-O2 -print-multi-os-directory`/./libiberty.an
( cd /usr/local/avr/lib/`gcc -g -O2 -print-multi-os-directory` ; chmod
644 ./libiberty.an ;ranlib ./libiberty.an )
mv -f /usr/local/avr/lib/`gcc -g -O2
-print-multi-os-directory`/./libiberty.an /usr/local/avr/lib/`gcc -g
-O2 -print-multi-os-directory`/./libiberty.a
if test -n ""; then \
          case "" in \
            /*)    thd=;; \
            *)     thd=/usr/local/avr/include/;; \
          esac; \
          /bin/bash ../../libiberty/../mkinstalldirs ${thd}; \
          for h in ../../libiberty/../include/ansidecl.h
../../libiberty/../include/demangle.h
../../libiberty/../include/dyn-string.h
../../libiberty/../include/fibheap.h
../../libiberty/../include/floatformat.h
../../libiberty/../include/hashtab.h
../../libiberty/../include/libiberty.h
../../libiberty/../include/objalloc.h
../../libiberty/../include/partition.h
../../libiberty/../include/safe-ctype.h
../../libiberty/../include/sort.h
../../libiberty/../include/splay-tree.h; do \
            /usr/bin/install -c -m 644 $h ${thd}; \
          done; \
        fi
make[3]: Entering directory
`/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty/testsuite'
make[3]: Nothing to be done for `install'.
make[3]: Leaving directory
`/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty/testsuite'
make[2]: Leaving directory
`/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty'
/bin/bash: line 3: cd: avr/libgcc: No such file or directory
make[1]: *** [install-target-libgcc] Error 1
make[1]: Leaving directory
`/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr'
make: *** [install] Error 2


It seems the build cannot find the folder avr/libgcc, but why?


When running, the libgcc error above shows:
avr-gcc  -mmcu=at90usb1287 -Wl,-Map=SCD.map SCD.o EMV.o halSCD.o
scdIO.o utils.o terminal.o  halSCD.S SCD.S    -o SCD.elf
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status


Info about the avr-gcc:
avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/4.5.2/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr -v
--program-prefix=avr- --with-gcc --with-gnu-ld --with-gnu-as
--with-dwarf2 --disable-libssp --enable-languages=c,c++
--disable-werror --disable-nls
Thread model: single
gcc version 4.5.2 (GCC)


And verbose output of running the command:
avr-gcc -v -mmcu=at90usb1287 -Wl,-Map=SCD.map SCD.o EMV.o halSCD.o
scdIO.o utils.o terminal.o  halSCD.S SCD.S    -o SCD.elf
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/4.5.2/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr -v
--program-prefix=avr- --with-gcc --with-gnu-ld --with-gnu-as
--with-dwarf2 --disable-libssp --enable-languages=c,c++
--disable-werror --disable-nls
Thread model: single
gcc version 4.5.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf'
 /usr/local/avr/libexec/gcc/avr/4.5.2/cc1 -E -lang-asm -quiet -v
-imultilib avr51 halSCD.S -mmcu=at90usb1287 -fno-directives-only -o
/tmp/ccPZdrIF.s
ignoring nonexistent directory
"/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/avr/lib/gcc/avr/4.5.2/include
 /usr/local/avr/lib/gcc/avr/4.5.2/include-fixed
 /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf'
 /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/as -v
-mmcu=at90usb1287 -o /tmp/ccAv4Kbo.o /tmp/ccPZdrIF.s
GNU assembler version 2.21 (avr) using BFD version (GNU Binutils) 2.21
COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf'
 /usr/local/avr/libexec/gcc/avr/4.5.2/cc1 -E -lang-asm -quiet -v
-imultilib avr51 SCD.S -mmcu=at90usb1287 -fno-directives-only -o
/tmp/ccPZdrIF.s
ignoring nonexistent directory
"/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/avr/lib/gcc/avr/4.5.2/include
 /usr/local/avr/lib/gcc/avr/4.5.2/include-fixed
 /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf'
 /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/as -v
-mmcu=at90usb1287 -o /tmp/ccswYC86.o /tmp/ccPZdrIF.s
GNU assembler version 2.21 (avr) using BFD version (GNU Binutils) 2.21
COMPILER_PATH=/usr/local/avr/libexec/gcc/avr/4.5.2/:/usr/local/avr/libexec/gcc/avr/4.5.2/:/usr/local/avr/libexec/gcc/avr/:/usr/local/avr/lib/gcc/avr/4.5.2/:/usr/local/avr/lib/gcc/avr/:/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/
LIBRARY_PATH=/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr51/:/usr/local/avr/lib/gcc/avr/4.5.2/:/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/
COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf'
 /usr/local/avr/libexec/gcc/avr/4.5.2/collect2 -m avr51 -Tdata
0x800100 -o SCD.elf
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr51/crtusb1286.o
-L/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr51
-L/usr/local/avr/lib/gcc/avr/4.5.2
-L/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib -Map=SCD.map
SCD.o EMV.o halSCD.o scdIO.o utils.o terminal.o /tmp/ccAv4Kbo.o
/tmp/ccswYC86.o -lgcc -lc -lgcc
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status


Thanks,
 Omar

Re: Error building gcc 4.5.2 for AVR

[Jonathan Wakely]

On 25 January 2011 14:30, Omar Choudary wrote:
> Hello,
>
> I am trying to build GCC 4.5.2 for the AVR target. See my script:
> http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh
>
> I have some troubles when building, see below, maybe you can
> help me; thanks:

Hi Omar,

Kai Ruottu replied to your other mail, CCing this list, but apparently
forgot to include you, you can read it here:
http://gcc.gnu.org/ml/gcc-help/2011-01/msg00352.html

I hope that mail is useful.

Re: Error building gcc 4.5.2 for AVR

[Omar Choudary]

Hi, thanks for this help, however it doesn't solve the problem.
Let me reply to his comments inline:

>> Generally the AVR case seems to be a special case.
Unfortunately... it would be nice to have it converging.

>> So this dummy GCC builder is expected to try to build one's toolchain
>> using the (should be) well-known '*-elf' embedded target toolchain
>> build process via configuring something like :
>>
>> .../configure --prefix=<something> --target=avr-elf --with-newlib

Actually, from the target specific instructions:
http://gcc.gnu.org/install/specific.html#avr
the avr target is just "avr", not "avr-elf"

This is also confirmed in the avr-libc page:
http://www.nongnu.org/avr-libc/user-manual/install__tools.html

which shows the configuration as:
../configure --prefix=$PREFIX --target=avr --enable-languages=c,c++
--disable-nls --disable-libssp --with-dwarf2

Although the avr-libc community is the most used by AVR users, the
instructions are made for GCC until version 4.3.4.
That's why I am trying to make the complete building scripts using GCC 4.5.2.

I should also mention that I did manage (before upgrading my system
and loosing it all) to install the tools using
GCC 4.5.1, based on the steps from avr-libc and some additional inputs
by Bingo (already in my current script).
Unfortunately I did not make a script at that time (which is why I am
creating one now), so I don't remember the exact options I used then.

>> If Omar really tries to support the GCC for AVR builders, one dummy
>> question is : "Why the expected '--with-newlib' is not used in his
>> GCC configure ?  This definitely is the option which defines the
>> case being "a generic embedded target case" and removes all kind of
>> checks and link tests with the "expected to exist prebuilt target C
>> library", which is the default for "a generic system target case".
>> The equation: "embedded" == "use the '--with-newlib'" should be known
>> quite well, at least what leaving it away would mean during the GCC
>> build...

I am not sure I quite understand if what I did was wrong (i.e. I
should have put the --with-newlib, or is a problem with the config
system).
However, I did not put the --with-newlib because as you mentioned, the
AVR is a special case and newlib is not used for AVR
(also I don't remember ever using this option to compile the AVR tools).
For AVR, the avr-libc (see link above) is used.

Anyway, I tried to configure using --with-newlib and I got the exact
same result:
make[3]: Entering directory
`/local/scratch/osc22/temp/build-avr/gcc-build-4.5.2/libiberty/testsuite'
make[3]: Nothing to be done for `install'.
make[3]: Leaving directory
`/local/scratch/osc22/temp/build-avr/gcc-build-4.5.2/libiberty/testsuite'
make[2]: Leaving directory
`/local/scratch/osc22/temp/build-avr/gcc-build-4.5.2/libiberty'
/bin/bash: line 3: cd: avr/libgcc: No such file or directory
make[1]: *** [install-target-libgcc] Error 1
make[1]: Leaving directory `/local/scratch/osc22/temp/build-avr/gcc-build-4.5.2'
make: *** [install] Error 2

If someone has the time to look, the entire log is available here:
http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/make_avr_gcc_452_newlib_nomultilib.log

Someone has commented that multilibs may not have been installed, so I
removed the --disable-multilib.
But same problem, see:
http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/make_avr_gcc_452_multilib_nonewlib.log

However, after a bit more searching on libgcc I found this post:
http://wiki.osdev.org/GCC_Cross-Compiler

and so I added the make-target-libgcc to my install script.
This seems to solve the issue, although I still get the original error
on ligbcc missing the first time. See the log:
http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/make_avr_gcc_452_multilib_libgcc.log

Therefore the script seems to be working now. My question now is why
the Error while building, should the libgcc be built before is being
searched? And what is the option of mentioning I want to add libgcc to
the configure script, if this is mandatory?

Thanks again.
 Omar



On Tue, Jan 25, 2011 at 8:31 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 25 January 2011 14:30, Omar Choudary wrote:
>> Hello,
>>
>> I am trying to build GCC 4.5.2 for the AVR target. See my script:
>> http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh
>>
>> I have some troubles when building, see below, maybe you can
>> help me; thanks:
>
> Hi Omar,
>
> Kai Ruottu replied to your other mail, CCing this list, but apparently
> forgot to include you, you can read it here:
> http://gcc.gnu.org/ml/gcc-help/2011-01/msg00352.html
>
> I hope that mail is useful.
>

Re: Error building gcc 4.5.2 for AVR

[Kai Ruottu]

26.1.2011 14:25, Omar Choudary kirjoitti:

>>> So this dummy GCC builder is expected to try to build one's toolchain
>>> using the (should be) well-known '*-elf' embedded target toolchain
>>> build process via configuring something like :
>>>
>>> .../configure --prefix=<something>  --target=avr-elf --with-newlib
>
> Actually, from the target specific instructions:
> http://gcc.gnu.org/install/specific.html#avr
> the avr target is just "avr", not "avr-elf"

Now for the AVR CPU there seems to be those two supported targets,
"avr-*-rtems" and "avr-*-*" and giving a bare "avr" will choose the
latter target - when configuring in 'gcc'...

But probably the original $target name was used in the main configure
and with a bare 'avr' the following in 'configure' would be ignored :

   avr-*-*)
     noconfigdirs="$noconfigdirs target-libiberty target-libstdc++-v3 
${libgcj} target-libssp"
     ;;

What really was weird is that your error came from producing 'libiberty'
when this build is disabled for 'avr-*-*' targets!

> This is also confirmed in the avr-libc page:
> http://www.nongnu.org/avr-libc/user-manual/install__tools.html
>
> which shows the configuration as:
> ./configure --prefix=$PREFIX --target=avr --enable-languages=c,c++
> --disable-nls --disable-libssp --with-dwarf2

I don't know why this "one-eyeness" :(  Generally people should be
aware of a bare CPU name like 'i686', 'powerpc', 'mips', 'h8300',
'm68k', 'm68hc12' etc. not defining anything more about the needed
target than its CPU. Maybe the bare 'avr' was chosen to tell that
there absolutely isn't any opsys (RTOS or something) for this CPU,
there never has been and is never expected to be. Neither there
will be no other object format in use for it than ELF.  Now there
however seems to be the RTEMS RTOS and for it a separate target
name...

Using at least the '<cpu>-<object-format>' target name like
'h8300-elf', 'm68hc11-elf', 'bfin-elf' etc. with the no-opsys
embedded targets has hovever been the common habit, so it would
be quite expected to someone who is a "newbie with AVR" to use
the assumed target name "avr-elf". Although maybe being a newbie
with AVR, one may have years of experience with other CPUs and
producing crosscompilers for them. So looking at the FSF docs
about "how do I produce a crosscompiler for some embedded CPU"
maybe isn't the first reaction. I myself would have thought AVR
already being supported in newlib when CPUs like 'm68hc1*' are
supported...

>>> If Omar really tries to support the GCC for AVR builders, one dummy
>>> question is : "Why the expected '--with-newlib' is not used in his
>>> GCC configure ?  This definitely is the option which defines the
>>> case being "a generic embedded target case" and removes all kind of
>>> checks and link tests with the "expected to exist prebuilt target C
>>> library", which is the default for "a generic system target case".
>>> The equation: "embedded" == "use the '--with-newlib'" should be known
>>> quite well, at least what leaving it away would mean during the GCC
>>> build...
>
> I am not sure I quite understand if what I did was wrong (i.e. I
> should have put the --with-newlib, or is a problem with the config
> system).

The 'gcc-4.5.2/configure' may have a bug when it doesn't see 'avr'
meaning the same a 'avr-*-*'... Getting at least 'libgcc' should
however be the goal. Traditionally this has succeeded if using
'--with-newlib' in configure or defining 'inhibit_libc' or something
in one of the target config headers. Then no target headers are
needed during the 'libgcc' configure and build. The configure option
'--without-headers' may be one more choice for this goal. Providing
at least the target headers, for the 'fixincludes' phase, however is
the recommendation...

For some reason you didn't get libgcc being produced :(

> However, I did not put the --with-newlib because as you mentioned, the
> AVR is a special case and newlib is not used for AVR
> (also I don't remember ever using this option to compile the AVR tools).
> For AVR, the avr-libc (see link above) is used.

But the 'avr-*-*' config template in 'gcc/config.gcc' includes newlib-
specific stuff. So something doesn't agree with your words... Is the
'avr-libc' some derivation of newlib or "similar enough" to it?
>
> Anyway, I tried to configure using --with-newlib and I got the exact
> same result:
> make[3]: Entering directory
> `/local/scratch/osc22/temp/build-avr/gcc-build-4.5.2/libiberty/testsuite'
> make[3]: Nothing to be done for `install'.

As told, this shouldn't ever happen because for 'avr-*-*' target there
is no build for 'libiberty'!

> However, after a bit more searching on libgcc I found this post:
> http://wiki.osdev.org/GCC_Cross-Compiler
>
> and so I added the make-target-libgcc to my install script.

So you used 'make all-gcc' there?  The normal 'make' seems to
work if the target name is 'avr-elf'. No 'libiberty' build at
all...

> This seems to solve the issue, although I still get the original error
> on ligbcc missing the first time. See the log:
> http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/make_avr_gcc_452_multilib_libgcc.log
>
> Therefore the script seems to be working now. My question now is why
> the Error while building, should the libgcc be built before is being
> searched? And what is the option of mentioning I want to add libgcc to
> the configure script, if this is mandatory?

Maybe you should provide a patch for the main 'configure' so that also
the bare 'avr' - if absolutely necessary for the one-eyed people who
should never become aware about any weird "RTOS"es etc. for AVR because
that would only mix their heads :) - would be seen as 'avr-*-*'. I
think that '$target' means the original, '$target-alias' some derived
or calculated name and the '$target-canonical' the 'cpu-vendor-system'
complete name which 'config.sub' will give...

Using the "compatible with other CPUs" 'avr-elf' target name is not any
problem for me.  BTW, the MinGW people with their bare 'mingw' as the
target name instead of 'i686-mingw32' or something, seem to have just
the same attitude : "There can be only one!". Generally Windozes and
MinGW tools for them could have been many : 'i386-mingw32',
'mips-mingw32', 'powerpc-mingw32', 'alpha-mingw' and 'ia64-mingw'. But
that maybe would have been too complicated for the poor Windoze users...
There was a rumour about Windoze for ARM which would mean 'arm-mingw32'
if some people would implement it...

So generally the only weird thing here is the requirement to use the
bare CPU name, 'avr', as the target name when with other CPUs adding
the (most common now) object format name '-elf', has not revealed any
attitude problems among the toolchain users...

Re: Error building gcc 4.5.2 for AVR

[Omar Choudary]

Well, the requirement for the "avr" target is explicitly mentioned on
the gcc website:
http://gcc.gnu.org/install/specific.html#avr

I am no expert in this so I cannot comment if it is strange or not. If
it is, maybe the avr-gcc community should take this into consideration
(I've added Eric from avr-gcc to the message).

However, Eric has nicely pointed to me that my hack to add libgcc is
useless. Instead I was using, wrong apparently, make all-gcc instead
of just make all.

I've updated my script and all works nicely now, no errors at all. The
final version is available here:
http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/install_avr_tools.sh

Thanks.
 Omar


On Wed, Jan 26, 2011 at 1:57 PM, Kai Ruottu <kai.ruottu@wippies.com> wrote:
> 26.1.2011 14:25, Omar Choudary kirjoitti:
>
>>>> So this dummy GCC builder is expected to try to build one's toolchain
>>>> using the (should be) well-known '*-elf' embedded target toolchain
>>>> build process via configuring something like :
>>>>
>>>> .../configure --prefix=<something>  --target=avr-elf --with-newlib
>>
>> Actually, from the target specific instructions:
>> http://gcc.gnu.org/install/specific.html#avr
>> the avr target is just "avr", not "avr-elf"
>
> Now for the AVR CPU there seems to be those two supported targets,
> "avr-*-rtems" and "avr-*-*" and giving a bare "avr" will choose the
> latter target - when configuring in 'gcc'...
>
> But probably the original $target name was used in the main configure
> and with a bare 'avr' the following in 'configure' would be ignored :
>
>  avr-*-*)
>    noconfigdirs="$noconfigdirs target-libiberty target-libstdc++-v3
> ${libgcj} target-libssp"
>    ;;
>
> What really was weird is that your error came from producing 'libiberty'
> when this build is disabled for 'avr-*-*' targets!
>
>> This is also confirmed in the avr-libc page:
>> http://www.nongnu.org/avr-libc/user-manual/install__tools.html
>>
>> which shows the configuration as:
>> ./configure --prefix=$PREFIX --target=avr --enable-languages=c,c++
>> --disable-nls --disable-libssp --with-dwarf2
>
> I don't know why this "one-eyeness" :(  Generally people should be
> aware of a bare CPU name like 'i686', 'powerpc', 'mips', 'h8300',
> 'm68k', 'm68hc12' etc. not defining anything more about the needed
> target than its CPU. Maybe the bare 'avr' was chosen to tell that
> there absolutely isn't any opsys (RTOS or something) for this CPU,
> there never has been and is never expected to be. Neither there
> will be no other object format in use for it than ELF.  Now there
> however seems to be the RTEMS RTOS and for it a separate target
> name...
>
> Using at least the '<cpu>-<object-format>' target name like
> 'h8300-elf', 'm68hc11-elf', 'bfin-elf' etc. with the no-opsys
> embedded targets has hovever been the common habit, so it would
> be quite expected to someone who is a "newbie with AVR" to use
> the assumed target name "avr-elf". Although maybe being a newbie
> with AVR, one may have years of experience with other CPUs and
> producing crosscompilers for them. So looking at the FSF docs
> about "how do I produce a crosscompiler for some embedded CPU"
> maybe isn't the first reaction. I myself would have thought AVR
> already being supported in newlib when CPUs like 'm68hc1*' are
> supported...
>
>>>> If Omar really tries to support the GCC for AVR builders, one dummy
>>>> question is : "Why the expected '--with-newlib' is not used in his
>>>> GCC configure ?  This definitely is the option which defines the
>>>> case being "a generic embedded target case" and removes all kind of
>>>> checks and link tests with the "expected to exist prebuilt target C
>>>> library", which is the default for "a generic system target case".
>>>> The equation: "embedded" == "use the '--with-newlib'" should be known
>>>> quite well, at least what leaving it away would mean during the GCC
>>>> build...
>>
>> I am not sure I quite understand if what I did was wrong (i.e. I
>> should have put the --with-newlib, or is a problem with the config
>> system).
>
> The 'gcc-4.5.2/configure' may have a bug when it doesn't see 'avr'
> meaning the same a 'avr-*-*'... Getting at least 'libgcc' should
> however be the goal. Traditionally this has succeeded if using
> '--with-newlib' in configure or defining 'inhibit_libc' or something
> in one of the target config headers. Then no target headers are
> needed during the 'libgcc' configure and build. The configure option
> '--without-headers' may be one more choice for this goal. Providing
> at least the target headers, for the 'fixincludes' phase, however is
> the recommendation...
>
> For some reason you didn't get libgcc being produced :(
>
>> However, I did not put the --with-newlib because as you mentioned, the
>> AVR is a special case and newlib is not used for AVR
>> (also I don't remember ever using this option to compile the AVR tools).
>> For AVR, the avr-libc (see link above) is used.
>
> But the 'avr-*-*' config template in 'gcc/config.gcc' includes newlib-
> specific stuff. So something doesn't agree with your words... Is the
> 'avr-libc' some derivation of newlib or "similar enough" to it?
>>
>> Anyway, I tried to configure using --with-newlib and I got the exact
>> same result:
>> make[3]: Entering directory
>> `/local/scratch/osc22/temp/build-avr/gcc-build-4.5.2/libiberty/testsuite'
>> make[3]: Nothing to be done for `install'.
>
> As told, this shouldn't ever happen because for 'avr-*-*' target there
> is no build for 'libiberty'!
>
>> However, after a bit more searching on libgcc I found this post:
>> http://wiki.osdev.org/GCC_Cross-Compiler
>>
>> and so I added the make-target-libgcc to my install script.
>
> So you used 'make all-gcc' there?  The normal 'make' seems to
> work if the target name is 'avr-elf'. No 'libiberty' build at
> all...
>
>> This seems to solve the issue, although I still get the original error
>> on ligbcc missing the first time. See the log:
>>
>> http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/make_avr_gcc_452_multilib_libgcc.log
>>
>> Therefore the script seems to be working now. My question now is why
>> the Error while building, should the libgcc be built before is being
>> searched? And what is the option of mentioning I want to add libgcc to
>> the configure script, if this is mandatory?
>
> Maybe you should provide a patch for the main 'configure' so that also
> the bare 'avr' - if absolutely necessary for the one-eyed people who
> should never become aware about any weird "RTOS"es etc. for AVR because
> that would only mix their heads :) - would be seen as 'avr-*-*'. I
> think that '$target' means the original, '$target-alias' some derived
> or calculated name and the '$target-canonical' the 'cpu-vendor-system'
> complete name which 'config.sub' will give...
>
> Using the "compatible with other CPUs" 'avr-elf' target name is not any
> problem for me.  BTW, the MinGW people with their bare 'mingw' as the
> target name instead of 'i686-mingw32' or something, seem to have just
> the same attitude : "There can be only one!". Generally Windozes and
> MinGW tools for them could have been many : 'i386-mingw32',
> 'mips-mingw32', 'powerpc-mingw32', 'alpha-mingw' and 'ia64-mingw'. But
> that maybe would have been too complicated for the poor Windoze users...
> There was a rumour about Windoze for ARM which would mean 'arm-mingw32'
> if some people would implement it...
>
> So generally the only weird thing here is the requirement to use the
> bare CPU name, 'avr', as the target name when with other CPUs adding
> the (most common now) object format name '-elf', has not revealed any
> attitude problems among the toolchain users...
>

RE: Error building gcc 4.5.2 for AVR

[Weddington, Eric]

Hi All,

I'm not familiar with the entire conversation that has been going on, but hopefully I can answer any questions if they come up.

To that end, some points:

- The "avr" target does not normally use newlib for the C library. The avr has it's own C library and project called "avr-libc" which can be found on Savannah. Avr-libc is licensed with the BSD license and has been around for about 10 years now. This is why we don't use --with-newlib.

- A few years back, the RTEMS folks (namely Joel) wanted to get RTEMS working for the AVR and they wanted to use newlib. I mentioned that no one in the AVR community was developing or maintaining newlib for the avr target. But I don't know anyone who is actually using RTEMS on the AVR or whether this target is maintained much in any parts of the toolchain. The RTEMS folks would have to chime in on this.

Eric Weddington
Atmel

> -----Original Message-----
> From: Omar Choudary [mailto:choudary.omar@gmail.com]
> Sent: Wednesday, January 26, 2011 10:18 AM
> To: Kai Ruottu
> Cc: Jonathan Wakely; gcc-help@gcc.gnu.org; Weddington, Eric
> Subject: Re: Error building gcc 4.5.2 for AVR
> 
> Well, the requirement for the "avr" target is explicitly mentioned on
> the gcc website:
> http://gcc.gnu.org/install/specific.html#avr
> 
> I am no expert in this so I cannot comment if it is strange or not. If
> it is, maybe the avr-gcc community should take this into consideration
> (I've added Eric from avr-gcc to the message).
> 
> However, Eric has nicely pointed to me that my hack to add libgcc is
> useless. Instead I was using, wrong apparently, make all-gcc instead
> of just make all.
> 
> I've updated my script and all works nicely now, no errors at all. The
> final version is available here:
> http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/install_avr_tools.sh
> 
> Thanks.
>  Omar
> 
> 
> On Wed, Jan 26, 2011 at 1:57 PM, Kai Ruottu <kai.ruottu@wippies.com>
> wrote:
> > 26.1.2011 14:25, Omar Choudary kirjoitti:
> >
> >>>> So this dummy GCC builder is expected to try to build one's toolchain
> >>>> using the (should be) well-known '*-elf' embedded target toolchain
> >>>> build process via configuring something like :
> >>>>
> >>>> .../configure --prefix=<something>  --target=avr-elf --with-newlib
> >>
> >> Actually, from the target specific instructions:
> >> http://gcc.gnu.org/install/specific.html#avr
> >> the avr target is just "avr", not "avr-elf"
> >
> > Now for the AVR CPU there seems to be those two supported targets,
> > "avr-*-rtems" and "avr-*-*" and giving a bare "avr" will choose the
> > latter target - when configuring in 'gcc'...
> >
> > But probably the original $target name was used in the main configure
> > and with a bare 'avr' the following in 'configure' would be ignored :
> >
> >  avr-*-*)
> >    noconfigdirs="$noconfigdirs target-libiberty target-libstdc++-v3
> > ${libgcj} target-libssp"
> >    ;;
> >
> > What really was weird is that your error came from producing 'libiberty'
> > when this build is disabled for 'avr-*-*' targets!
> >
> >> This is also confirmed in the avr-libc page:
> >> http://www.nongnu.org/avr-libc/user-manual/install__tools.html
> >>
> >> which shows the configuration as:
> >> ./configure --prefix=$PREFIX --target=avr --enable-languages=c,c++
> >> --disable-nls --disable-libssp --with-dwarf2
> >
> > I don't know why this "one-eyeness" :(  Generally people should be
> > aware of a bare CPU name like 'i686', 'powerpc', 'mips', 'h8300',
> > 'm68k', 'm68hc12' etc. not defining anything more about the needed
> > target than its CPU. Maybe the bare 'avr' was chosen to tell that
> > there absolutely isn't any opsys (RTOS or something) for this CPU,
> > there never has been and is never expected to be. Neither there
> > will be no other object format in use for it than ELF.  Now there
> > however seems to be the RTEMS RTOS and for it a separate target
> > name...
> >
> > Using at least the '<cpu>-<object-format>' target name like
> > 'h8300-elf', 'm68hc11-elf', 'bfin-elf' etc. with the no-opsys
> > embedded targets has hovever been the common habit, so it would
> > be quite expected to someone who is a "newbie with AVR" to use
> > the assumed target name "avr-elf". Although maybe being a newbie
> > with AVR, one may have years of experience with other CPUs and
> > producing crosscompilers for them. So looking at the FSF docs
> > about "how do I produce a crosscompiler for some embedded CPU"
> > maybe isn't the first reaction. I myself would have thought AVR
> > already being supported in newlib when CPUs like 'm68hc1*' are
> > supported...
> >
> >>>> If Omar really tries to support the GCC for AVR builders, one dummy
> >>>> question is : "Why the expected '--with-newlib' is not used in his
> >>>> GCC configure ?  This definitely is the option which defines the
> >>>> case being "a generic embedded target case" and removes all kind of
> >>>> checks and link tests with the "expected to exist prebuilt target C
> >>>> library", which is the default for "a generic system target case".
> >>>> The equation: "embedded" == "use the '--with-newlib'" should be known
> >>>> quite well, at least what leaving it away would mean during the GCC
> >>>> build...
> >>
> >> I am not sure I quite understand if what I did was wrong (i.e. I
> >> should have put the --with-newlib, or is a problem with the config
> >> system).
> >
> > The 'gcc-4.5.2/configure' may have a bug when it doesn't see 'avr'
> > meaning the same a 'avr-*-*'... Getting at least 'libgcc' should
> > however be the goal. Traditionally this has succeeded if using
> > '--with-newlib' in configure or defining 'inhibit_libc' or something
> > in one of the target config headers. Then no target headers are
> > needed during the 'libgcc' configure and build. The configure option
> > '--without-headers' may be one more choice for this goal. Providing
> > at least the target headers, for the 'fixincludes' phase, however is
> > the recommendation...
> >
> > For some reason you didn't get libgcc being produced :(
> >
> >> However, I did not put the --with-newlib because as you mentioned, the
> >> AVR is a special case and newlib is not used for AVR
> >> (also I don't remember ever using this option to compile the AVR
> tools).
> >> For AVR, the avr-libc (see link above) is used.
> >
> > But the 'avr-*-*' config template in 'gcc/config.gcc' includes newlib-
> > specific stuff. So something doesn't agree with your words... Is the
> > 'avr-libc' some derivation of newlib or "similar enough" to it?
> >>
> >> Anyway, I tried to configure using --with-newlib and I got the exact
> >> same result:
> >> make[3]: Entering directory
> >> `/local/scratch/osc22/temp/build-avr/gcc-build-
> 4.5.2/libiberty/testsuite'
> >> make[3]: Nothing to be done for `install'.
> >
> > As told, this shouldn't ever happen because for 'avr-*-*' target there
> > is no build for 'libiberty'!
> >
> >> However, after a bit more searching on libgcc I found this post:
> >> http://wiki.osdev.org/GCC_Cross-Compiler
> >>
> >> and so I added the make-target-libgcc to my install script.
> >
> > So you used 'make all-gcc' there?  The normal 'make' seems to
> > work if the target name is 'avr-elf'. No 'libiberty' build at
> > all...
> >
> >> This seems to solve the issue, although I still get the original error
> >> on ligbcc missing the first time. See the log:
> >>
> >>
> http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/make_avr_gcc_452_multilib_lib
> gcc.log
> >>
> >> Therefore the script seems to be working now. My question now is why
> >> the Error while building, should the libgcc be built before is being
> >> searched? And what is the option of mentioning I want to add libgcc to
> >> the configure script, if this is mandatory?
> >
> > Maybe you should provide a patch for the main 'configure' so that also
> > the bare 'avr' - if absolutely necessary for the one-eyed people who
> > should never become aware about any weird "RTOS"es etc. for AVR because
> > that would only mix their heads :) - would be seen as 'avr-*-*'. I
> > think that '$target' means the original, '$target-alias' some derived
> > or calculated name and the '$target-canonical' the 'cpu-vendor-system'
> > complete name which 'config.sub' will give...
> >
> > Using the "compatible with other CPUs" 'avr-elf' target name is not any
> > problem for me.  BTW, the MinGW people with their bare 'mingw' as the
> > target name instead of 'i686-mingw32' or something, seem to have just
> > the same attitude : "There can be only one!". Generally Windozes and
> > MinGW tools for them could have been many : 'i386-mingw32',
> > 'mips-mingw32', 'powerpc-mingw32', 'alpha-mingw' and 'ia64-mingw'. But
> > that maybe would have been too complicated for the poor Windoze users...
> > There was a rumour about Windoze for ARM which would mean 'arm-mingw32'
> > if some people would implement it...
> >
> > So generally the only weird thing here is the requirement to use the
> > bare CPU name, 'avr', as the target name when with other CPUs adding
> > the (most common now) object format name '-elf', has not revealed any
> > attitude problems among the toolchain users...
> >