AVR toolchain update

[bardo]

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

[Allan McRae-3]

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

[Laszlo Papp]

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@...>

> 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]

2009/7/9 Allan McRae <allan@...>:
> 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

[Laszlo Papp]

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@...>

> 2009/7/9 Allan McRae <allan@...>:
> > 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
>

[bardo]

2009/7/11 taptaptap dödödö <djszapi2@...>:
> 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

[Laszlo Papp]

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@...>

> 2009/7/11 taptaptap dödödö <djszapi2@...>:
> > 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
>

[bardo]

2009/7/17 taptaptap dödödö <djszapi2@...>:
> 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 ;)

[bardo]

2009/7/17 bardo <ilbardo@...>:
> 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

[Laszlo Papp]

Well, is it okay or shall i see at evening ?

2009/7/17 bardo <ilbardo@...>

> 2009/7/17 bardo <ilbardo@...>:
> > 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
>

[bardo]

2009/7/17 taptaptap dödödö <djszapi2@...>:
> 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 =)

[Laszlo Papp]

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@...> wrote:

> 2009/7/17 taptaptap dödödö <djszapi2@...>:
> > 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]

2009/7/17 taptaptap dödödö <djszapi2@...>:
> 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

[bardo]

2009/7/17 bardo <ilbardo@...>:

> 2009/7/17 taptaptap dödödö <djszapi2@...>:
>> 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

[Laszlo Papp]

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@...> wrote:

> 2009/7/17 bardo <ilbardo@...>:
> > 2009/7/17 taptaptap dödödö <djszapi2@...>:
> >> 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
>