From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17293 invoked by alias); 26 Jan 2011 18:17:50 -0000 Received: (qmail 17273 invoked by uid 22791); 26 Jan 2011 18:17:48 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,TW_GB,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from newsmtp5.atmel.com (HELO sjogate2.atmel.com) (204.2.163.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Jan 2011 18:17:41 +0000 Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id p0QIErsp024240; Wed, 26 Jan 2011 10:14:54 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Error building gcc 4.5.2 for AVR Date: Wed, 26 Jan 2011 18:17:00 -0000 Message-ID: <258DDD1F44B6ED4AAFD4370847CF58D50EF90387@csomb01.corp.atmel.com> In-Reply-To: References: <4D40283D.1090608@wippies.com> From: "Weddington, Eric" To: "Omar Choudary" , "Kai Ruottu" Cc: "Jonathan Wakely" , Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg00382.txt.bz2 Hi All, I'm not familiar with the entire conversation that has been going on, but h= opefully 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 worki= ng for the AVR and they wanted to use newlib. I mentioned that no one in th= e AVR community was developing or maintaining newlib for the avr target. Bu= t I don't know anyone who is actually using RTEMS on the AVR or whether thi= s 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 >=20 > Well, the requirement for the "avr" target is explicitly mentioned on > the gcc website: > http://gcc.gnu.org/install/specific.html#avr >=20 > 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). >=20 > 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. >=20 > 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 >=20 > Thanks. > Omar >=20 >=20 > On Wed, Jan 26, 2011 at 1:57 PM, Kai Ruottu > 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=3D =A0--target=3Davr-elf --with-ne= wlib > >> > >> 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 : > > > > =A0avr-*-*) > > =A0 =A0noconfigdirs=3D"$noconfigdirs target-libiberty target-libstdc++-= v3 > > ${libgcj} target-libssp" > > =A0 =A0;; > > > > 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=3D$PREFIX --target=3Davr --enable-languages=3Dc,c= ++ > >> --disable-nls --disable-libssp --with-dwarf2 > > > > I don't know why this "one-eyeness" :( =A0Generally 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. =A0Now there > > however seems to be the RTEMS RTOS and for it a separate target > > name... > > > > Using at least the '-' 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 ? =A0This 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" =3D=3D "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? =A0The 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. =A0BTW, 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... > >