binutils patching failed

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just tried to use scripts from the
sticky thread for installing avr-gcc.
./buildavr-no-insight.sh gave me the error message:
patch: **** Only garbage was found in the patch input.
(./buildavr-no-insight.sh) binutils patching failed
On examining the diff files, I noted that
binutils-patch-atmega256x.diff and
gcc-patch-attribute_alias.diff are html.
They begin with .

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I remember that the scripts automatically download patches from web pages. If these web pages have moved or if there was an error it would explain why you got the html.

Open the files in a web browser and see what they contain. Maybe they contain a message what went wrong, e.g. a html error message or some hint where the file moved. You could try to find the files somewhere else and download them manually.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They both say FILE REMOVED.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please use the most recent version of the script.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
Please use the most recent version of the script.
I though that I had. I got it from the head of the sticky thread.
notice on source of script wrote:
Last edited by Bingo600 on Dec 23, 2007 - 01:57 PM; edited 18 times in total
Is there a more recent version than the one at beginning of the sticky thread?

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@skeeve

I just tried "getpatches" from the 2 "top" ones , and i can't see any problems.

As for the 3'rd (the gcc 4.1.2) the patches are allready in the downloaded file , and it clearly states "skip the getpatches step"
I think it's the 3'rd you are using , as it is the only one with a binutils-patch-atmega256x.diff.

And i suppose you are trying to get the patches from the net , instead of using the included ones.

Edit: The most recent is the "Top one"

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo600 wrote:
As for the 3'rd (the gcc 4.1.2) the patches are allready in the downloaded file , and it clearly states "skip the getpatches step"
I think it's the 3'rd you are using , as it is the only one with a binutils-patch-atmega256x.diff.

And i suppose you are trying to get the patches from the net , instead of using the included ones.

Edit: The most recent is the "Top one"

Ah. Read the readme, not just the article. Thanks.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
Bingo600 wrote:
As for the 3'rd (the gcc 4.1.2) the patches are allready in the downloaded file , and it clearly states "skip the getpatches step"
I think it's the 3'rd you are using , as it is the only one with a binutils-patch-atmega256x.diff.

And i suppose you are trying to get the patches from the net , instead of using the included ones.

Edit: The most recent is the "Top one"

Ah. Read the readme, not just the article. Thanks.

Btw: Jörg released a more recent avr-libc , in the 1.4x train.

Edit : http://download.savannah.gnu.org...

You might want to change "getfiles" to get that one or just manually download it.

Then replace the avr-libc version number in the beginning of the "buildavr-no..." script.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or try these build scripts (shameless self plug):
https://www.avrfreaks.net/index.p...

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Brad

I haven't gotten around to trying them yet :oops:

But they seems nice.

You based the script on th WinAVR repository , didn't you ?

What version are they building ??

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Currently 4.2.2, but one of the reasons I created them was that you can switch versions by changing one number in one file.

Last time I checked the 4.3.0 version was pulled again due to problems.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

20080430 is released, with GCC 4.3.0. Patches are in the WinAVR CVS repository.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The latest patches for binutils 2.18 don't seem to apply cleanly to the binutils 2.18 source. The problem starts in 57-binutils-2.18-atmega1284p.patch. This is the error:

Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
1 out of 1 hunk ignored -- saving rejects to file gas/config/tc-avr.c.rej
1 out of 1 hunk FAILED -- saving rejects to file gas/doc/c-avr.texi.rej

I also updated my build scripts to report patch errors better.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using stock FSF binutils 2.18? Or are using a later snapshot, or perhaps Linux binutils 2.18.50?

My patches are for stock FSF binutils 2.18.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I believe I am using the stock FSF version. This is the URL:
http://ftp.gnu.org/gnu/binutils/...

The same version worked with the patches until recently. If you have a linux system, try these scripts and you should see the problem:
https://www.avrfreaks.net/index.p...

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any word on this Eric? These patches still don't apply correctly to the binutils 2.18 source.
http://winavr.cvs.sourceforge.ne...

I looked into the issue, and found that these patches are duplicates:

50-7-binutils-2.18-atmega1284p.patch
57-binutils-2.18-atmega1284p.patch

And the these are very similar and conflicting:

50-9-binutils-2.18-avr35.patch
59-binutils-2.18-avr35.patch

It looks to me like 50-9-binutils-2.18-avr35.patch is the most recent version.

If I manually delete patches 57-binutils-2.18-atmega1284p.patch and 59-binutils-2.18-avr35.patch, then all binutils patches apply ok.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe I should start a new thread for this, but anyway, now that the patches from winavr CVS are applied binutils 2.18 doesn't build. Here are the errors:

/home/brad/toolchain/source/binutils-2.18/bfd/cpu-avr.c:92: error: 'bfd_mach_avrxmega1' undeclared here (not in a function)
/home/brad/toolchain/source/binutils-2.18/bfd/cpu-avr.c:95: error: 'bfd_mach_avrxmega2' undeclared here (not in a function)
/home/brad/toolchain/source/binutils-2.18/bfd/cpu-avr.c:98: error: 'bfd_mach_avrxmega3' undeclared here (not in a function)
/home/brad/toolchain/source/binutils-2.18/bfd/cpu-avr.c:101: error: 'bfd_mach_avrxmega4' undeclared here (not in a function)
/home/brad/toolchain/source/binutils-2.18/bfd/cpu-avr.c:104: error: 'bfd_mach_avrxmega5' undeclared here (not in a function)
/home/brad/toolchain/source/binutils-2.18/bfd/cpu-avr.c:107: error: 'bfd_mach_avrxmega6' undeclared here (not in a function)
/home/brad/toolchain/source/binutils-2.18/bfd/cpu-avr.c:110: error: 'bfd_mach_avrxmega7' undeclared here (not in a function)

It looks to me like patch 52-binutils-2.18-xmega.patch is incomplete. When I grep for another architecture like bfd_mach_avr6, I find the following in the patched binutils source:

./bfd/archures.c:.#define bfd_mach_avr6		6
./bfd/bfd-in2.h:#define bfd_mach_avr6          6
./bfd/cpu-avr.c:  N (22, bfd_mach_avr6, "avr:6", FALSE, & arch_info_struct[6]),
./bfd/elf32-avr.c:    case bfd_mach_avr6:
./bfd/elf32-avr.c:	  e_set = bfd_mach_avr6;
./bfd/archures.c.orig:.#define bfd_mach_avr6		6
./gas/config/tc-avr.c:  {"avr6",       AVR_ISA_ALL,     bfd_mach_avr6},
./gas/config/tc-avr.c:  {"atmega2560", AVR_ISA_M256,    bfd_mach_avr6},
./gas/config/tc-avr.c:  {"atmega2561", AVR_ISA_M256,    bfd_mach_avr6},

But when I grep for one of the architectures in the errors above like bfd_mach_avrxmega1 I only find

./bfd/archures.c:.#define bfd_mach_avrxmega1 101
./bfd/cpu-avr.c:  N (24, bfd_mach_avrxmega1, "avr:101", FALSE, & arch_info_struct[7]),
./gas/config/tc-avr.c:  {"avrxmega1",  AVR_ISA_XMEGA,   bfd_mach_avrxmega1},

Seems to be missing defines in ./bfd/bfd-in2.h and maybe some code in ./bfd/elf32-avr.c

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do a clean checkout of the 'patches' module using the "WinAVR-20080430" tag.