ATTiny10 and 7.3.0 Toolchain

[Wayne Holder]

Sorry for being off topic, but I could really use some help.

Arduino 1.8.10 recently upgraded the AVR toolchain in the macOS version from 32 bit 5.4.0 to 64 bit 7.3.0 in order to support macOs Catalina.  However, the  7.3.0 toolchain has an odd problem when trying to compile and link code for the attiny10 series of micro controllers.  To demonstrate this, I extracted the toolchain from the Mac version of Arduino 1.8.10 and then ran it from the command line to compile and link a simple test program, such as:

 

#include <avr/io.h>

int main () {
  DDRB |= (1 << PB0);

  while (true) {
    PORTB |= (1 << PB0);
    PORTB &= ~(1 << PB0);
  }
}
 

I can use the 7.3.0 toolchain to compile and link this code for the attiny85, like this:

 

  ./avr/bin/avr-g++ -c -g -Os -w -std=gnu++11 -mmcu=attiny85 -I ./ test.cpp -o test.cpp.o
  ./avr/bin/avr-gcc -w -Os -g -mmcu=attiny85 -o test.elf test.cpp.o -L ./ -lm 
 

and it works just fine.  But, if i change the -mmcu switch from attiny85 to attiny10, the command to link the code (2nd line) spews out the following errors:

 

/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: cannot find crtattiny10.o: No such file or directory
/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: skipping incompatible /Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/lib/libm.a when searching for -lm
/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: cannot find -lm
/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: skipping incompatible /Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/libgcc.a when searching for -lgcc
/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: cannot find -lgcc
/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: skipping incompatible /Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/lib/libm.a when searching for -lm
/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: cannot find -lm
/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: skipping incompatible /Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/lib/libc.a when searching for -lc
/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: cannot find -lc
/Users/wholder/Desktop/temp/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld: cannot find -lattiny10
collect2: error: ld returned 1 exit status
 

Curiously, the file crtattiny10.o is available in the toolchain at relative path: ./avr/lib/avrtiny/crtattiny10.o

 

Can anyone help me figure out what's going on here?  It looks like something got broken in the 7.3.0 toolchain that previously worked in the 5.4.0 toolchain, as I've successfully used 5.4.0 to compile and link attiny10 code for some time. 

 

Wayne

[William Westfield]

cannot find crtattiny10.o: No such file or directory

Guessing, I’d bet that the “device-specs” file (from Microchip?) is now based on the PACKS structure that Microchip is using to distribute new device info, but the directory structure for the libraries is still based on the older specs.

Does it work if you download the ATtiny packs (from http://packs.download.atmel.com/) is give the various pack-related compile switches?

avr-gcc -g  -I /Downloads/Atmel.ATtiny_DFP.1.3.229/include/  -B /Downloads/Atmel.ATtiny_DFP.1.3.229/gcc/dev/attiny10  -mmcu=attiny10 …

For instance, you had 

the file crtattiny10.o is available in the toolchain at relative path: ./avr/lib/avrtiny/crtattiny10.o

but in the packs directory I see an extra level of directory hierarchy:

…/gcc/dev/attiny10/avrtiny/crtattiny10.o 

Note that Microchip is still shipping gcc 5.4 as “current.”

BillW/WestfW

[William Westfield]

It seemed like good guess…   :-(

I’m now thinking that the more relevant error message is this one:

skipping incompatible /Users/wholder/Desktop/toolchain problem/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/lib/libm.a

For some reason, it deciding that the tiny10 libraries (and probably the crt file as well) are incompatible with the linker and/or .o file and/or something else.  This is known to happen when there are 32 and 64bit versions of libraries, but I can’t figure out why it would apply to AVR files, all of which look to be 32bit (even compiled with the 64bit compilers.)

I’ve got 1.8.10 installed now, and I can duplicate your problem and I’m poking around at stuff.  But so far, I can’t see any reason that tiny10 fails and tiny13 (for example) works OK…

BillW

[Wayne Holder]

I'm glad to hear you can replicate the issue with the attiny10.  Can you also confirm that the link phase also fails with the following MCUs?

  avrtiny: attiny4, attiny5, attiny9

  avrxmega7: atxmega128a1, atxmega128a1u, atxmega128a4u

I keep thinking there is a clue to be gained from these other fails.

Wayne

[William Westfield]

Can you also confirm that the link phase also fails with the following MCUs?

  avrtiny: attiny4, attiny5, attiny9

  avrxmega7: atxmega128a1, atxmega128a1u, atxmega128a4u

Confirmed.

Also Attiny102, ATtiny104, ATtiny20, ATtiny40

These are from “avrtiny” and “avrxmega128” families.

It looks like:

…/avr/lib/avrtiny and .../avr/lib/avrxmega7 exist, and that’s where libm and the crt* files live.

…/lib/gcc/avr/7.3.0/atxmega7 and …/lib/gcc/avr/7.3.0/avrtiny do NOT exist.  This is where (architecture-specific) libgcc.a should be.  It’s seeming to pick up a libgcc from a non-architecture-specific directory, and I suspect that that’s also messing up it’s path choice for the other files.  Or something like that.

I don’t know enough about building gcc to know how to build those files, or why they wouldn’t be there.

BillW