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