From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28037 invoked by alias); 26 Jan 2011 17:17:54 -0000 Received: (qmail 28025 invoked by uid 22791); 26 Jan 2011 17:17:52 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_GB X-Spam-Check-By: sourceware.org Received: from mail-yw0-f47.google.com (HELO mail-yw0-f47.google.com) (209.85.213.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Jan 2011 17:17:44 +0000 Received: by ywi6 with SMTP id 6so227960ywi.20 for ; Wed, 26 Jan 2011 09:17:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.209.15 with SMTP id h15mr5156884ang.2.1296062260400; Wed, 26 Jan 2011 09:17:40 -0800 (PST) Received: by 10.100.232.20 with HTTP; Wed, 26 Jan 2011 09:17:40 -0800 (PST) In-Reply-To: <4D40283D.1090608@wippies.com> References: <4D40283D.1090608@wippies.com> Date: Wed, 26 Jan 2011 17:17:00 -0000 Message-ID: Subject: Re: Error building gcc 4.5.2 for AVR From: Omar Choudary To: Kai Ruottu Cc: Jonathan Wakely , gcc-help@gcc.gnu.org, "Weddington, Eric" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00381.txt.bz2 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 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-newl= ib >> >> 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 kn= own >>>> 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_l= ibgcc.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... >