* Re: Error building gcc 4.5.2 for AVR [not found] ` <AANLkTimRfRvV6mHhw1sZq5CsrbF4bdtTaL4vAKeQb7AR@mail.gmail.com> @ 2011-01-25 10:25 ` Kai Ruottu 2011-01-25 10:55 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: Kai Ruottu @ 2011-01-25 10:25 UTC (permalink / raw) To: gcc-help 25.1.2011 1:57, Jonathan Wakely kirjoitti: > On 24 January 2011 22:49, Omar Choudary wrote: >> >> I am creating a script for building GCC 4.5.2 for the AVR target: >> http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh >> >> I have some troubles when building GCC-4.5.2, see below, maybe you can >> help me; thanks: > > This question is off-topic on this mailing list, please send such > questions to the gcc-help@gcc.gnu.org list, as described > http://gcc.gnu.org/lists.html > > Since you're using a third-party's build script, not the GCC > installation instructions, you might be able to ask the author of that > script for support. The asker here seems to be the "supporter" :( Generally the AVR case seems to be a special case. The gcc-4.5.2 configury system gives the complete target name : [root@localhost gcc-4.5.2]# ./config.sub avr avr-unknown-none for the bare "avr" target name used by Omar. The plain vanilla gcc-4.5.2 configury recognizes this as the second of the two following templates : avr-*-rtems*) tm_file="avr/avr.h dbxelf.h avr/rtems.h rtems.h newlib-stdint.h" tmake_file="avr/t-avr t-rtems avr/t-rtems" extra_gcc_objs="driver-avr.o avr-devices.o" extra_objs="avr-devices.o" ;; avr-*-*) tm_file="avr/avr.h dbxelf.h newlib-stdint.h" use_gcc_stdint=wrap extra_gcc_objs="driver-avr.o avr-devices.o" extra_objs="avr-devices.o" ;; ie. probably as a "plain vanilla newlib-based embedded target". So, what a totally dummy GCC builder would expect the AVR target to use is : 1. it uses ELF as its object format 2. it uses newlib as its target C library just like many others targets met earlier... 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 and probably "succeeds" nicely when writing 'make'... Before becoming aware that newlib really doesn't support AVR :( and there are more "specific" notes for this "special" target in : http://gcc.gnu.org/install/specific.html#avr I tried this "dummy builder from the street" approach and getting the toolchain succeeded nicely with the plain vanilla gcc-4.5.2 sources, no errors ever : [root@localhost build]# cd gcc [root@localhost gcc]# ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: avr-elf Configured with: ../configure --build=i686-linux-gnu --host=i686-linux-gnu --target=avr-elf --enable-languages=c,c++ --with-newlib --disable-shared --disable-threads --disable-nls --with-gxx-include-dir=/usr/local/include/c++/4.5.2 --enable-version-specific-runtime-libs --with-pkgversion='by Kai Ruottu 2011q1' Thread model: single gcc version 4.5.2 (by Kai Ruottu 2011q1) >> make[2]: Leaving directory >> `/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty' >> /bin/bash: line 3: cd: avr/libgcc: No such file or directory >> make[1]: *** [install-target-libgcc] Error 1 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... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error building gcc 4.5.2 for AVR 2011-01-25 10:25 ` Error building gcc 4.5.2 for AVR Kai Ruottu @ 2011-01-25 10:55 ` Jonathan Wakely 0 siblings, 0 replies; 8+ messages in thread From: Jonathan Wakely @ 2011-01-25 10:55 UTC (permalink / raw) To: Kai Ruottu; +Cc: gcc-help On 25 January 2011 10:25, Kai Ruottu wrote: > 25.1.2011 1:57, Jonathan Wakely kirjoitti: > >> On 24 January 2011 22:49, Omar Choudary wrote: >>> >>> I am creating a script for building GCC 4.5.2 for the AVR target: >>> http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh >>> >>> I have some troubles when building GCC-4.5.2, see below, maybe you can >>> help me; thanks: >> >> This question is off-topic on this mailing list, please send such >> questions to the gcc-help@gcc.gnu.org list, as described >> http://gcc.gnu.org/lists.html >> >> Since you're using a third-party's build script, not the GCC >> installation instructions, you might be able to ask the author of that >> script for support. > > The asker here seems to be the "supporter" :( Oops! Sorry, I didn't notice that. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Error building gcc 4.5.2 for AVR [not found] ` <AANLkTinfEKRqPOYWfjQafw1grCVA6ewxJ4q-RASD-pxC@mail.gmail.com> [not found] ` <AANLkTimRfRvV6mHhw1sZq5CsrbF4bdtTaL4vAKeQb7AR@mail.gmail.com> @ 2011-01-25 14:31 ` Omar Choudary 2011-01-25 20:31 ` Jonathan Wakely 1 sibling, 1 reply; 8+ messages in thread From: Omar Choudary @ 2011-01-25 14:31 UTC (permalink / raw) To: gcc-help Hello, I am trying to build GCC 4.5.2 for the AVR target. See my script: http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh I have some troubles when building, see below, maybe you can help me; thanks: ... make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty/testsuite' /bin/bash ../../libiberty/../mkinstalldirs /usr/local/avr/lib/`gcc -g -O2 -print-multi-os-directory` /usr/bin/install -c -m 644 ./libiberty.a /usr/local/avr/lib/`gcc -g -O2 -print-multi-os-directory`/./libiberty.an ( cd /usr/local/avr/lib/`gcc -g -O2 -print-multi-os-directory` ; chmod 644 ./libiberty.an ;ranlib ./libiberty.an ) mv -f /usr/local/avr/lib/`gcc -g -O2 -print-multi-os-directory`/./libiberty.an /usr/local/avr/lib/`gcc -g -O2 -print-multi-os-directory`/./libiberty.a if test -n ""; then \ case "" in \ /*) thd=;; \ *) thd=/usr/local/avr/include/;; \ esac; \ /bin/bash ../../libiberty/../mkinstalldirs ${thd}; \ for h in ../../libiberty/../include/ansidecl.h ../../libiberty/../include/demangle.h ../../libiberty/../include/dyn-string.h ../../libiberty/../include/fibheap.h ../../libiberty/../include/floatformat.h ../../libiberty/../include/hashtab.h ../../libiberty/../include/libiberty.h ../../libiberty/../include/objalloc.h ../../libiberty/../include/partition.h ../../libiberty/../include/safe-ctype.h ../../libiberty/../include/sort.h ../../libiberty/../include/splay-tree.h; do \ /usr/bin/install -c -m 644 $h ${thd}; \ done; \ fi make[3]: Entering directory `/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty/testsuite' make[3]: Nothing to be done for `install'. make[3]: Leaving directory `/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty/testsuite' make[2]: Leaving directory `/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr/libiberty' /bin/bash: line 3: cd: avr/libgcc: No such file or directory make[1]: *** [install-target-libgcc] Error 1 make[1]: Leaving directory `/local/scratch/osc22/temp/build-avr/gcc-4.5.2/buildavr' make: *** [install] Error 2 It seems the build cannot find the folder avr/libgcc, but why? When running, the libgcc error above shows: avr-gcc -mmcu=at90usb1287 -Wl,-Map=SCD.map SCD.o EMV.o halSCD.o scdIO.o utils.o terminal.o halSCD.S SCD.S -o SCD.elf /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status Info about the avr-gcc: avr-gcc -v Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/4.5.2/lto-wrapper Target: avr Configured with: ../configure --target=avr --prefix=/usr/local/avr -v --program-prefix=avr- --with-gcc --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-libssp --enable-languages=c,c++ --disable-werror --disable-nls Thread model: single gcc version 4.5.2 (GCC) And verbose output of running the command: avr-gcc -v -mmcu=at90usb1287 -Wl,-Map=SCD.map SCD.o EMV.o halSCD.o scdIO.o utils.o terminal.o halSCD.S SCD.S -o SCD.elf Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/4.5.2/lto-wrapper Target: avr Configured with: ../configure --target=avr --prefix=/usr/local/avr -v --program-prefix=avr- --with-gcc --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-libssp --enable-languages=c,c++ --disable-werror --disable-nls Thread model: single gcc version 4.5.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf' /usr/local/avr/libexec/gcc/avr/4.5.2/cc1 -E -lang-asm -quiet -v -imultilib avr51 halSCD.S -mmcu=at90usb1287 -fno-directives-only -o /tmp/ccPZdrIF.s ignoring nonexistent directory "/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/sys-include" #include "..." search starts here: #include <...> search starts here: /usr/local/avr/lib/gcc/avr/4.5.2/include /usr/local/avr/lib/gcc/avr/4.5.2/include-fixed /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf' /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/as -v -mmcu=at90usb1287 -o /tmp/ccAv4Kbo.o /tmp/ccPZdrIF.s GNU assembler version 2.21 (avr) using BFD version (GNU Binutils) 2.21 COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf' /usr/local/avr/libexec/gcc/avr/4.5.2/cc1 -E -lang-asm -quiet -v -imultilib avr51 SCD.S -mmcu=at90usb1287 -fno-directives-only -o /tmp/ccPZdrIF.s ignoring nonexistent directory "/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/sys-include" #include "..." search starts here: #include <...> search starts here: /usr/local/avr/lib/gcc/avr/4.5.2/include /usr/local/avr/lib/gcc/avr/4.5.2/include-fixed /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf' /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/as -v -mmcu=at90usb1287 -o /tmp/ccswYC86.o /tmp/ccPZdrIF.s GNU assembler version 2.21 (avr) using BFD version (GNU Binutils) 2.21 COMPILER_PATH=/usr/local/avr/libexec/gcc/avr/4.5.2/:/usr/local/avr/libexec/gcc/avr/4.5.2/:/usr/local/avr/libexec/gcc/avr/:/usr/local/avr/lib/gcc/avr/4.5.2/:/usr/local/avr/lib/gcc/avr/:/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ LIBRARY_PATH=/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr51/:/usr/local/avr/lib/gcc/avr/4.5.2/:/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/ COLLECT_GCC_OPTIONS='-v' '-mmcu=at90usb1287' '-o' 'SCD.elf' /usr/local/avr/libexec/gcc/avr/4.5.2/collect2 -m avr51 -Tdata 0x800100 -o SCD.elf /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr51/crtusb1286.o -L/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr51 -L/usr/local/avr/lib/gcc/avr/4.5.2 -L/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/lib -Map=SCD.map SCD.o EMV.o halSCD.o scdIO.o utils.o terminal.o /tmp/ccAv4Kbo.o /tmp/ccswYC86.o -lgcc -lc -lgcc /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc /usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status Thanks, Omar ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error building gcc 4.5.2 for AVR 2011-01-25 14:31 ` Omar Choudary @ 2011-01-25 20:31 ` Jonathan Wakely 2011-01-26 12:25 ` Omar Choudary 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Wakely @ 2011-01-25 20:31 UTC (permalink / raw) To: Omar Choudary; +Cc: gcc-help On 25 January 2011 14:30, Omar Choudary wrote: > Hello, > > I am trying to build GCC 4.5.2 for the AVR target. See my script: > http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh > > I have some troubles when building, see below, maybe you can > help me; thanks: Hi Omar, Kai Ruottu replied to your other mail, CCing this list, but apparently forgot to include you, you can read it here: http://gcc.gnu.org/ml/gcc-help/2011-01/msg00352.html I hope that mail is useful. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error building gcc 4.5.2 for AVR 2011-01-25 20:31 ` Jonathan Wakely @ 2011-01-26 12:25 ` Omar Choudary 2011-01-26 13:57 ` Kai Ruottu 0 siblings, 1 reply; 8+ messages in thread From: Omar Choudary @ 2011-01-26 12:25 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help Hi, thanks for this help, however it doesn't solve the problem. Let me reply to his comments inline: >> Generally the AVR case seems to be a special case. Unfortunately... it would be nice to have it converging. >> 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" 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 Although the avr-libc community is the most used by AVR users, the instructions are made for GCC until version 4.3.4. That's why I am trying to make the complete building scripts using GCC 4.5.2. I should also mention that I did manage (before upgrading my system and loosing it all) to install the tools using GCC 4.5.1, based on the steps from avr-libc and some additional inputs by Bingo (already in my current script). Unfortunately I did not make a script at that time (which is why I am creating one now), so I don't remember the exact options I used then. >> 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). 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. 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'. make[3]: Leaving directory `/local/scratch/osc22/temp/build-avr/gcc-build-4.5.2/libiberty/testsuite' make[2]: Leaving directory `/local/scratch/osc22/temp/build-avr/gcc-build-4.5.2/libiberty' /bin/bash: line 3: cd: avr/libgcc: No such file or directory make[1]: *** [install-target-libgcc] Error 1 make[1]: Leaving directory `/local/scratch/osc22/temp/build-avr/gcc-build-4.5.2' make: *** [install] Error 2 If someone has the time to look, the entire log is available here: http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/make_avr_gcc_452_newlib_nomultilib.log Someone has commented that multilibs may not have been installed, so I removed the --disable-multilib. But same problem, see: http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/make_avr_gcc_452_multilib_nonewlib.log 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. 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? Thanks again. Omar On Tue, Jan 25, 2011 at 8:31 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > On 25 January 2011 14:30, Omar Choudary wrote: >> Hello, >> >> I am trying to build GCC 4.5.2 for the AVR target. See my script: >> http://www.cl.cam.ac.uk/~osc22/files/install_avr_tools.sh >> >> I have some troubles when building, see below, maybe you can >> help me; thanks: > > Hi Omar, > > Kai Ruottu replied to your other mail, CCing this list, but apparently > forgot to include you, you can read it here: > http://gcc.gnu.org/ml/gcc-help/2011-01/msg00352.html > > I hope that mail is useful. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error building gcc 4.5.2 for AVR 2011-01-26 12:25 ` Omar Choudary @ 2011-01-26 13:57 ` Kai Ruottu 2011-01-26 17:17 ` Omar Choudary 0 siblings, 1 reply; 8+ messages in thread From: Kai Ruottu @ 2011-01-26 13:57 UTC (permalink / raw) To: Omar Choudary; +Cc: Jonathan Wakely, gcc-help 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... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Error building gcc 4.5.2 for AVR 2011-01-26 13:57 ` Kai Ruottu @ 2011-01-26 17:17 ` Omar Choudary 2011-01-26 18:17 ` Weddington, Eric 0 siblings, 1 reply; 8+ messages in thread From: Omar Choudary @ 2011-01-26 17:17 UTC (permalink / raw) To: Kai Ruottu; +Cc: Jonathan Wakely, gcc-help, Weddington, Eric 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... > ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Error building gcc 4.5.2 for AVR 2011-01-26 17:17 ` Omar Choudary @ 2011-01-26 18:17 ` Weddington, Eric 0 siblings, 0 replies; 8+ messages in thread From: Weddington, Eric @ 2011-01-26 18:17 UTC (permalink / raw) To: Omar Choudary, Kai Ruottu; +Cc: Jonathan Wakely, gcc-help Hi All, I'm not familiar with the entire conversation that has been going on, but hopefully 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 working for the AVR and they wanted to use newlib. I mentioned that no one in the AVR community was developing or maintaining newlib for the avr target. But I don't know anyone who is actually using RTEMS on the AVR or whether this 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 > > 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_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. 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... > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-01-26 18:17 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <AANLkTikGSyXsg-KbQdK4awYOhjVyTTnn+sA8YgBTwuJX@mail.gmail.com> [not found] ` <AANLkTinfEKRqPOYWfjQafw1grCVA6ewxJ4q-RASD-pxC@mail.gmail.com> [not found] ` <AANLkTimRfRvV6mHhw1sZq5CsrbF4bdtTaL4vAKeQb7AR@mail.gmail.com> 2011-01-25 10:25 ` Error building gcc 4.5.2 for AVR Kai Ruottu 2011-01-25 10:55 ` Jonathan Wakely 2011-01-25 14:31 ` Omar Choudary 2011-01-25 20:31 ` Jonathan Wakely 2011-01-26 12:25 ` Omar Choudary 2011-01-26 13:57 ` Kai Ruottu 2011-01-26 17:17 ` Omar Choudary 2011-01-26 18:17 ` Weddington, Eric
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).