On Thu, Apr 23, 2020 at 01:09:19AM +0200, Jeremie Courreges-Anglas wrote: > On Wed, Apr 22 2020, Andrea Fleckenstein <afl...@mailbox.org> wrote: > > Hello, > > > > devel/avrdude is currently version 5.11 > > avrdude 6.x includes support for direct reading of ELF files via > > libelf. OpenBSD's sys/exec_elf.h does not include an e_machine entry for > > EM_AVR, which causes compilation of 6.3 to fail as follows: > > > > fileio.c:910:15: error: use of undeclared identifier 'EM_AVR' > > machine = EM_AVR; > > ^ > > I can get it to compile (on amd64 -current) by just writing: > > > > #define EM_AVR 83 > > > > at the top of fileio.c. '83' is a value I got here: > > https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html > > I don't know if there is a preferred standardization of these values. > > > > now it builds and I can upload a .hex file to my arduino uno and > > everything seems to work fine. > > [...] > > > What do people think of this? Reasons to go for one approach vs another? > > Any potential problems with just setting EM_AVR that I need to be aware > > of? > > This looks like the most straightforward solution, but we could > certainly push for the addition of EM_AVR to base libelf (#ifndef > EM_AVR, #define EM_AVR...). > > > I'm not an AVR expert by any means, just wanted to do some playing > > around and thought updating our 9-year old avrdude version might be nice. > > Indeed. Probably Tracey will want to give it a try. But this sounds > like something that should be committed post-6.7. >
I can certainly test this here in the future. Having newer avrdude would be great. None of the ESP "suite of tools" uses avrdude, so those won't be affected. I'm working on a ATTiny project, which would be a good test case for this. :D > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE -- Tracey Emery
