we at the nanoFramework team do seem to suffer from this <what-ever-it-is> behavior too.
While using the 8 version we first got a complaint about a deprecated -mstructure-size-boundary=8 and of course had to remove that option. Doing a new compile without that option resulted in the same behavior.
[build] C:\dev\tools\arm_gcc\821\bin\arm-none-eabi-objcopy: C:/dev/github/nf-interpreter/build/nanoBooter.hex 64-bit address 0x4b4fa308000000 out of range for Intel Hex file
[build] C:\dev\tools\arm_gcc\821\bin\arm-none-eabi-objcopy:C:/dev/github/nf-interpreter/build/nanoBooter.hex: bad value
Doing the same work around as mentioned above by Edwin Hoeks fixed the objcopy behavior.
This too is running on a 64-bit windows 10 system.
Hi All,
we at the nanoFramework team do seem to suffer from this <what-ever-it-is> behavior too.
While using the 8 version we first got a complaint about a deprecated -mstructure- size-boundary= 8 and of course had to remove that option. Doing a new compile without that option resulted in the same behavior.
[build] C:\dev\ tools\arm_ gcc\821\ bin\arm- none-eabi- objcopy: C:/dev/ github/ nf-interpreter/ build/nanoBoote r.hex 64-bit address 0x4b4fa308000000 out of range for Intel Hex file tools\arm_ gcc\821\ bin\arm- none-eabi- objcopy: C:/dev/ github/ nf-interpreter/ build/nanoBoote r.hex: bad value
[build] C:\dev\
Doing the same work around as mentioned above by Edwin Hoeks fixed the objcopy behavior.
This too is running on a 64-bit windows 10 system.
In case you require more info the complete log is to be found here https:/ /github. com/nanoframewo rk/Home/ issues/ 443