Dear Maintainer,

   Currently I'm using the microchip avr-gcc-7.3. Planning to update to
   a more up-to-date compiler I updated to trixie which provides
   avr-gcc-14.2. Now avr-objcopy appears to fail when converting the hex
   into elf: "/usr/bin/avr-objcopy -I ihex firmware.hex -O binary
   firmware.bin" gives "invalid operation".

   I've used zakkemble, microchip and my own cross toolchain with
   success.

Some further research I found the following:

https://linux.debian.bugs.dist.narkive.com/Dy11dvaC/bug-1093895-objcopy-fails-with-invalid-operation


https://fossies.org/linux/binutils/ChangeLog.git

2025-01-27  Alan Modra  <amodra@gmail.com>

   57

   58 PR32599, objcopy -I ihex:

invalid operation

  59 Restores ihex get_symtab_upper_bound to what it was prior to commit

   60 394a3f4f8d.  This will enable objcopy of other no-sym formats too.

   61

   62 PR 32599

   63 * libbfd-in.h (_bfd_nosymbols_get_symtab_upper_bound): Define

   64 as _bfd_long_bfd_0.

   65 * libbfd.h: Regenerate.

   66

   67 (cherry picked from commit fd45211245d0f1027a0c3ab606e3253eda779e68)

Hi,

I've been recently trying to build a new package which depends on the
AVR toolchain, and this bug was exercised during the package build:

	dh_auto_build --sourcedir=firmware
		cd firmware && make -j16 INSTALL="install --strip-program=true"
	make[2]: Entering directory '/build/reproducible-path/micronucleus-2.6/firmware'
	Building Micronucleus configuration: t85_default
		 text	   data	    bss	    dec	    hex	filename
				0	   1522	      0	   1522	    5f2	main.hex
	8K  Device -- Codesize: 1522 bytes, BOOTLOADER_ADDRESS: 0x1A00, Free user memory 6650 bytes.
	16K Device -- Codesize: 1522 bytes, BOOTLOADER_ADDRESS: 0x3A00, Free user memory 14842 bytes.
	avr-objcopy: main.hex: invalid operation

From what I could see, this is https://bugs.debian.org/1093895, which
was forwarded upstream [1]. That bug was fixed in version
2.43.90.20250127-1 (commit b8a2b31) of src:binutils by applying the
patch you mentioned [2].

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=32599
[2] https://salsa.debian.org/toolchain-team/binutils/-/commit/b8a2b312638841da25c4d367e14d81d43ad5b5f3

Although src:binutils-avr is using the same upstream and same patches as
src:binutils, the package hasn't been rebuilt since the binutils-source
was upgraded to 2.43.90.20250127-1 (which happened back in Jan 27, 2025
[3]), and therefore it has never been built from the patched source.

It seems that Steve Meliza attempted to prepare a new release in the
Salsa repository to fix the issue [4], but it hasn't gone to the
archive. I wonder if that's because of the packaging issues discussed in
the open merge request in the repository [5].

[3] https://tracker.debian.org/news/1609685/accepted-binutils-2439020250127-1-source-into-unstable
[4] https://salsa.debian.org/debian/binutils-avr/-/commit/1d2202ff8d4aab44fffd822ce33be407e67c3e4c
[5] https://salsa.debian.org/debian/binutils-avr/-/merge_requests/11

As far as I understand, this means the package as it is today is not
reproducible and each rebuild can use a different version depending on
the binutils-source package available on the archive when the (re)build
happens. Therefore, this also means that any rebuild or new upload will
fix this hex to binary invalid operation bug (and also upgrade to a new
upstream version).

Building binutils-avr from the source [6] on Debian unstable today
renders the package to ship binutils 2.46:

```
$ avr-objcopy --version
GNU objcopy (GNU Binutils) 2.46
Copyright (C) 2026 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
```

Although the source package metadata will claim it to be 2.45-1.

[6] https://salsa.debian.org/debian/binutils-avr/-/commit/76341722ddda50fcdb41586b24a732a977f9247a

If there is anything I can do to help resolve this situation, I'll be
glad to do so.

Henrique,

It is my fault that the AVR toolchain has not been updated yet. I plan to get
back to working on this soon, maybe even today.

Thanks
-Steve