[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

From: Timo Sandmann
Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
Date: Mon, 2 Feb 2009 13:53:17 +0100

Am 02.02.2009 um 09:33 schrieb Ruud Vlaming:
I guess you applied the patch "40-avr-libc-1.6.4-fix-attiny13a-
arch.patch"? With this patch I need to use bootstrap (because the
patch moves the attiny13a from avr2 to avr25), without it the avr- libc
builds fine here without bootstrap.
I do. So the point is, when you apply a patch, then there is / may be
a need to bootstrap? Can this also hold true for other tools? I for
example never did so and experienced no problems until now.

If the applied patch needs a modified makefile, you have to update the makefile via bootstrap / automake or the patch itself has to contain these updates.

BTW: For me as a user it's even worse to build binutils with all the
patches from winavr, because AFAIK the autoconf / autoheader version
has to be exactly 2.59, not newer.
Can you be more specific? Is far as i know i apply all patches and did not
encounter this problem.

When I applied the xmega-patches to binutils 2.19, the build-process failed: ../../binutils-2.19/bfd/elf32-avr.c: In function 'bfd_elf_avr_final_write_processing': ../../binutils-2.19/bfd/elf32-avr.c:1331: error: 'bfd_mach_avrxmega1' undeclared (first use in this function)


So I configured with "--enable-maintainer-mode" to run automake during the build-process. But that leads to: configure.ac:26: error: Please use exactly Autoconf 2.59 instead of 2.63.
config/override.m4:24: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:26: the top level
autom4te: /opt/local/bin/gm4 failed with exit status: 1
make: *** [../binutils-2.19/configure] Error 1

Using autoconf 2.59 instead of 2.63 solved that. AFAIK that's something binutils-specific.

From the present discussion you may have
understood that the version has to be 2.59<=version<=2.62. But that
point is addressed by a patch now (use mine or Eric's). What's the
source of limitation?

That's for the avr-libc bootstrap-script, but it's different for binutils (and not avr-specific).

My point was, that it would be easier for (non-windows) users, if the patches delivered with winavr would also contain the makefile-updates, so that's unnecessary to run automake / bootstrap to build a toolchain with the same patches as included in the winavr release.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]