From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21370 invoked by alias); 26 Jan 2011 13:57:39 -0000 Received: (qmail 21352 invoked by uid 22791); 26 Jan 2011 13:57:38 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_GB X-Spam-Check-By: sourceware.org Received: from wmh1.mail.saunalahti.fi (HELO wmh1.mail.saunalahti.fi) (62.142.5.133) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Jan 2011 13:57:31 +0000 Received: from [192.168.1.3] (dsl-olubrasgw1-fe15f900-207.dhcp.inet.fi [84.249.21.207]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kai.ruottu@wippies.com) by wmh1.mail.saunalahti.fi (Postfix) with ESMTPSA id 7DD741FC066; Wed, 26 Jan 2011 15:57:22 +0200 (EET) Message-ID: <4D40283D.1090608@wippies.com> Date: Wed, 26 Jan 2011 13:57:00 -0000 From: Kai Ruottu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Omar Choudary CC: Jonathan Wakely , gcc-help@gcc.gnu.org Subject: Re: Error building gcc 4.5.2 for AVR References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00374.txt.bz2 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= --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 '-' 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...