RE: Error building gcc 4.5.2 for AVR

["Weddington, Eric" <Eric.Weddington@atmel.com>]

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