Re: Error building gcc 4.5.2 for AVR

[Omar Choudary <choudary.omar@gmail.com>]

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