[aur-general] AVR toolchain update
I've been delaying this update for quite a while. At the moment I've got a working binutils-avr, and I'm trying to make gcc work. I'm still not on the 4.4 train, which IIRC introduced the gcc-libs package. I have to admit that the gcc-libs role is not really clear to me, and I'm not sure I need an AVR-compiled version, but my gcc-avr build still fails and I don't know why, so I have no way to check. Can someone who knows more than me shed some light on this? Thanks, Corrado
bardo wrote:
I've been delaying this update for quite a while. At the moment I've got a working binutils-avr, and I'm trying to make gcc work. I'm still not on the 4.4 train, which IIRC introduced the gcc-libs package. I have to admit that the gcc-libs role is not really clear to me, and I'm not sure I need an AVR-compiled version, but my gcc-avr build still fails and I don't know why, so I have no way to check. Can someone who knows more than me shed some light on this?
You do not need a gcc-libs-avr as the whole puropse of you package is to privide the compiler. gcc-libs was split so people did not need the compiler on their system. If you post some details about the build failure you are having, I may be able to help. Allan
It must work :)) I use AVR toolchain for programming AVR microprocessors. What's the exact problem with it ? I think you saw this: http://avrwiki.com/wiki/index.php/Building_AVR_GCC Sincerelly, Laszlo Papp 2009/7/9 bardo <ilbardo@gmail.com>
I've been delaying this update for quite a while. At the moment I've got a working binutils-avr, and I'm trying to make gcc work. I'm still not on the 4.4 train, which IIRC introduced the gcc-libs package. I have to admit that the gcc-libs role is not really clear to me, and I'm not sure I need an AVR-compiled version, but my gcc-avr build still fails and I don't know why, so I have no way to check. Can someone who knows more than me shed some light on this?
Thanks, Corrado
2009/7/9 Allan McRae <allan@archlinux.org>:
You do not need a gcc-libs-avr as the whole puropse of you package is to privide the compiler. gcc-libs was split so people did not need the compiler on their system.
Great, that's what i suspected but I wasn't sure.
If you post some details about the build failure you are having, I may be able to help.
The build fails (in a clean chroot) on libgcc's configure: ----- Checking multilib configuration for libgcc... mkdir -p -- avr/libgcc Configuring in avr/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /bin/install -c checking for gawk... gawk checking build system type... i686-pc-linux-gnu checking host system type... avr-unknown-none checking for avr-ar... avr-ar checking for avr-lipo... avr-lipo checking for avr-nm... /build/src/gcc-4.4.0/build/./gcc/nm checking for avr-ranlib... avr-ranlib checking for avr-strip... avr-strip checking whether ln -s works... yes checking for avr-gcc... /build/src/gcc-4.4.0/build/./gcc/xgcc -B/build/src/gcc-4.4.0/build/./gcc/ -B/usr/avr/bin/ -B/usr/avr/lib/ -isystem /usr/avr/include -isystem /usr/avr/sys-include checking for suffix of object files... configure: error: in `/build/src/gcc-4.4.0/build/avr/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make[1]: Leaving directory `/build/src/gcc-4.4.0/build' make: *** [all] Error 2 ==> ERROR: Build Failed. ----- Here's the config.log: http://pastebin.com/m2c4de4d2 Here's my gcc-avr PKGBUILD: http://pastebin.com/m7ed5e45c Here's binutils-avr build files: http://www.bardland.org/files/binutils-avr-2.19.1-1.src.tar.gz The build is successful outside makepkg, and the problem seems to be path-related. Thanks for any help, Corrado
Hello bardo! I've spent more time with it too! The problem is, it tries to build with that C(XX)FLAGS, which is in your /etc/makepkg.conf! It can be a hack, but works for me. Set the CXXFLAGS="" && CFLAGS="" for the building session, and can be built well. Hope this helps Sincerelly, Laszlo Papp 2009/7/11 bardo <ilbardo@gmail.com>
2009/7/9 Allan McRae <allan@archlinux.org>:
You do not need a gcc-libs-avr as the whole puropse of you package is to privide the compiler. gcc-libs was split so people did not need the compiler on their system.
Great, that's what i suspected but I wasn't sure.
If you post some details about the build failure you are having, I may be able to help.
The build fails (in a clean chroot) on libgcc's configure:
----- Checking multilib configuration for libgcc... mkdir -p -- avr/libgcc Configuring in avr/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /bin/install -c checking for gawk... gawk checking build system type... i686-pc-linux-gnu checking host system type... avr-unknown-none checking for avr-ar... avr-ar checking for avr-lipo... avr-lipo checking for avr-nm... /build/src/gcc-4.4.0/build/./gcc/nm checking for avr-ranlib... avr-ranlib checking for avr-strip... avr-strip checking whether ln -s works... yes checking for avr-gcc... /build/src/gcc-4.4.0/build/./gcc/xgcc -B/build/src/gcc-4.4.0/build/./gcc/ -B/usr/avr/bin/ -B/usr/avr/lib/ -isystem /usr/avr/include -isystem /usr/avr/sys-include checking for suffix of object files... configure: error: in `/build/src/gcc-4.4.0/build/avr/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make[1]: Leaving directory `/build/src/gcc-4.4.0/build' make: *** [all] Error 2 ==> ERROR: Build Failed. -----
Here's the config.log: http://pastebin.com/m2c4de4d2 Here's my gcc-avr PKGBUILD: http://pastebin.com/m7ed5e45c Here's binutils-avr build files: http://www.bardland.org/files/binutils-avr-2.19.1-1.src.tar.gz
The build is successful outside makepkg, and the problem seems to be path-related.
Thanks for any help, Corrado
2009/7/11 taptaptap dödödö <djszapi2@gmail.com>:
Hello bardo!
I've spent more time with it too! The problem is, it tries to build with that C(XX)FLAGS, which is in your /etc/makepkg.conf! It can be a hack, but works for me. Set the CXXFLAGS="" && CFLAGS="" for the building session, and can be built well.
Thanks, as we discussed in private the toolchain has now been updated, even though I've been notified by various sources that it is broken for some AVR architectures. Since I haven't been able to solve the problem quickly, I'm asking for some help on the list. So, here's an explanation of what I found out until now. What's happening: avr-ld, for some reason, doesn't descend into /usr/avr/lib/ subdirectories while searching for object files, so it doesn't find arch-specific linker files. I've found an old bug report that oulines the same problem, even though with no solution posted: http://savannah.nongnu.org/bugs/?22539 A (temporary and very ugly) workaround, for those who work with only one architecture, is linking files in, for example, /usr/avr/lib/avr4/ to /usr/avr/lib/, paying attention to backup files by the same name (libm.a, libc.a...). In the meantime I'm trying hard to solve the issue, but I can't really find where the problem lies, so if anybody has any knowledge of toolchain-building and has suggestions to share, please write :) Thanks, Corrado
Hello Bardo! I will look at this at evening, after my work :) Hope i can help you. Sincerelly, Laszlo Papp 2009/7/17 bardo <ilbardo@gmail.com>
Hello bardo!
I've spent more time with it too! The problem is, it tries to build with that C(XX)FLAGS, which is in your /etc/makepkg.conf! It can be a hack, but works for me. Set the CXXFLAGS="" && CFLAGS="" for
2009/7/11 taptaptap dödödö <djszapi2@gmail.com>: the
building session, and can be built well.
Thanks, as we discussed in private the toolchain has now been updated, even though I've been notified by various sources that it is broken for some AVR architectures. Since I haven't been able to solve the problem quickly, I'm asking for some help on the list. So, here's an explanation of what I found out until now.
What's happening: avr-ld, for some reason, doesn't descend into /usr/avr/lib/ subdirectories while searching for object files, so it doesn't find arch-specific linker files. I've found an old bug report that oulines the same problem, even though with no solution posted: http://savannah.nongnu.org/bugs/?22539
A (temporary and very ugly) workaround, for those who work with only one architecture, is linking files in, for example, /usr/avr/lib/avr4/ to /usr/avr/lib/, paying attention to backup files by the same name (libm.a, libc.a...).
In the meantime I'm trying hard to solve the issue, but I can't really find where the problem lies, so if anybody has any knowledge of toolchain-building and has suggestions to share, please write :)
Thanks, Corrado
2009/7/17 taptaptap dödödö <djszapi2@gmail.com>:
Hello Bardo!
I will look at this at evening, after my work :) Hope i can help you.
Thanks, I hope you can help me too ;)
2009/7/17 bardo <ilbardo@gmail.com>:
A (temporary and very ugly) workaround, for those who work with only one architecture, is linking files in, for example, /usr/avr/lib/avr4/ to /usr/avr/lib/, paying attention to backup files by the same name (libm.a, libc.a...).
Ingo Becker notified me of a much better workaround: add -B/usr/avr/lib/yourarch to the gcc command line. For example: $ avr-gcc -mcpu=atmega8 -O2 -Wall -B/usr/avr/lib/avr4 source.c
Well, is it okay or shall i see at evening ? 2009/7/17 bardo <ilbardo@gmail.com>
2009/7/17 bardo <ilbardo@gmail.com>:
A (temporary and very ugly) workaround, for those who work with only one architecture, is linking files in, for example, /usr/avr/lib/avr4/ to /usr/avr/lib/, paying attention to backup files by the same name (libm.a, libc.a...).
Ingo Becker notified me of a much better workaround: add -B/usr/avr/lib/yourarch to the gcc command line. For example: $ avr-gcc -mcpu=atmega8 -O2 -Wall -B/usr/avr/lib/avr4 source.c
2009/7/17 taptaptap dödödö <djszapi2@gmail.com>:
Well, is it okay or shall i see at evening ?
Unless it's a new gcc "feature", which I highly doubt, no, it's not ok, it's just a workaround =)
Bardo! First of all, you didn't add this file to the CVS, i can't test it. binutils-2.19-as-needed.patch On Fri, Jul 17, 2009 at 5:13 PM, bardo <ilbardo@gmail.com> wrote:
2009/7/17 taptaptap dödödö <djszapi2@gmail.com>:
Well, is it okay or shall i see at evening ?
Unless it's a new gcc "feature", which I highly doubt, no, it's not ok, it's just a workaround =)
2009/7/17 taptaptap dödödö <djszapi2@gmail.com>:
Bardo!
First of all, you didn't add this file to the CVS, i can't test it.
binutils-2.19-as-needed.patch
I should have done it... CVS isn't updating anymore, we've benn moved to a shiny new svn ;) Anyway, it's the same patch in the offical binutils, so you can find it in /var/abs/core/binutils/ :)Anyway utils/ :)Anyway
2009/7/17 bardo <ilbardo@gmail.com>:
2009/7/17 taptaptap dödödö <djszapi2@gmail.com>:
Bardo!
First of all, you didn't add this file to the CVS, i can't test it.
binutils-2.19-as-needed.patch
I should have done it... CVS isn't updating anymore, we've benn moved to a shiny new svn ;) Anyway, it's the same patch in the offical binutils, so you can find it in /var/abs/core/binutils/ :)Anyway utils/ :)Anyway
I think I got it! A user named pullmoll wrote a very useful comment in gcc-avr's AUR page. It didn't like the --disable-multilib flag, which purpose I had evidently mistaken and is clear to me now... that was the meaning of multiple architecture support ;) I'm uploading gcc-avr-4.4.0-2 now for x86_64, i686 will follow shortly. Thanks everybody for the help! Corrado
Ehh Bardo! I've told that last time not to use it :) I'm happy not neccessary to hack it, you're great :) Sincerelly, Laszlo Papp On Fri, Jul 17, 2009 at 11:20 PM, bardo <ilbardo@gmail.com> wrote:
2009/7/17 bardo <ilbardo@gmail.com>:
2009/7/17 taptaptap dödödö <djszapi2@gmail.com>:
Bardo!
First of all, you didn't add this file to the CVS, i can't test it.
binutils-2.19-as-needed.patch
I should have done it... CVS isn't updating anymore, we've benn moved to a shiny new svn ;) Anyway, it's the same patch in the offical binutils, so you can find it in /var/abs/core/binutils/ :)Anyway utils/ :)Anyway
I think I got it! A user named pullmoll wrote a very useful comment in gcc-avr's AUR page. It didn't like the --disable-multilib flag, which purpose I had evidently mistaken and is clear to me now... that was the meaning of multiple architecture support ;)
I'm uploading gcc-avr-4.4.0-2 now for x86_64, i686 will follow shortly.
Thanks everybody for the help!
Corrado
participants (3)
-
Allan McRae
-
bardo
-
taptaptap dödödö