same issue exists in arm-none-eabi compiler +++ This bug was initially created as a clone of Bug #1134394 +++ Description of problem: When using the Arduino IDE to build one of the included examples, it compiles fine but linking fails. Version-Release number of selected component (if applicable): arduino.noarch 1:1.0.5-8.fc21 How reproducible: Almost Trivial Steps to Reproduce: 1. Run arduino IDE, in preferences check boxe for verbose compile 2. Click the "up" arrow button (open) and chose one of the examples (doesn't matter which) 3. Click the check-mark (verify) button Actual results: ... avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o /tmp/build8503997909648707358.tmp/Blink.cpp.elf /tmp/build8503997909648707358.tmp/Blink.cpp.o /tmp/build8503997909648707358.tmp/core.a -L/tmp/build8503997909648707358.tmp -lm /usr/lib/gcc/avr/4.9.1/../../../../avr/bin/ld: skipping incompatible /usr/lib/gcc/avr/4.9.1/avr5/libgcc.a when searching for -lgcc /usr/lib/gcc/avr/4.9.1/../../../../avr/bin/ld: skipping incompatible /usr/lib/gcc/avr/4.9.1/libgcc.a when searching for -lgcc /usr/lib/gcc/avr/4.9.1/../../../../avr/bin/ld: cannot find -lgcc collect2: error: ld returned 1 exit status Expected results: Linking successful, then converts elf to hex (format) with avr-binutils, displays success message. Additional info: This can be reproduced w/o the Arduino IDE, but setting up AVR build environment is much less trivial to reproduce this bug than just using the IDE. I have not yet tried rawhide. --- Additional comment from Chris Evich on 2014-08-27 08:59:29 EDT --- Reproduced same linking failure with rawhide packages: avr-binutils x86_64 1:2.24-2.fc22 avr-gcc x86_64 4.9.1-2.fc22 avr-gcc-c++ x86_64 4.9.1-2.fc22 avr-gdb x86_64 7.1-11.fc22 --- Additional comment from Michal Hlavinka on 2014-08-27 10:47:08 EDT --- I've just tried to compile quite big project and it was working fine. Please try to find steps how to reproduce this without using arduino ide. Thanks --- Additional comment from Chris Evich on 2014-08-27 11:42:06 EDT --- Building w/o the IDE is possible using https://github.com/queezythegreat/arduino-cmake and I just noticed it includes an example. However the build is failing well before even touching the arduino-specifc bits with any compiler... $ git clone https://github.com/queezythegreat/arduino-cmake.git arduino-cmake Cloning into 'arduino-cmake'... remote: Counting objects: 2096, done. remote: Total 2096 (delta 0), reused 0 (delta 0) Receiving objects: 100% (2096/2096), 4.16 MiB | 5.25 MiB/s, done. Resolving deltas: 100% (720/720), done. Checking connectivity... done. $ cd arduino-cmake $ mkdir build; cd build $ cmake .. -- The C compiler identification is GNU 4.9.1 -- The CXX compiler identification is GNU 4.9.1 -- Arduino SDK version 1.0.5: /usr/share/arduino -- Check for working C compiler: /usr/lib64/ccache/avr-gcc -- Check for working C compiler: /usr/lib64/ccache/avr-gcc -- broken CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:61 (message): ...cut... /usr/lib64/ccache/avr-gcc -g -Os -mcall-prologues -ffunction-sections -fdata-sections -Wl,--gc-sections -lm CMakeFiles/cmTryCompileExec3150891695.dir/testCCompiler.c.obj -o cmTryCompileExec3150891695 /usr/lib/gcc/avr/4.9.1/../../../../avr/bin/ld: skipping incompatible /usr/lib/gcc/avr/4.9.1/libgcc.a when searching for -lgcc /usr/lib/gcc/avr/4.9.1/../../../../avr/bin/ld: cannot find -lgcc collect2: error: ld returned 1 exit status ...cut... The complete error is quite long, but that seems to be the important part and matches the trouble the IDE is having. In any case, that's a bit more of a lower-level yet simpler reproducer. Hope that helps. --- Additional comment from Chris Evich on 2014-08-28 09:46:13 EDT --- Is there anything else I can provide that would help find and/or determine if this is a bug or setup problem? --- Additional comment from Michal Hlavinka on 2014-08-29 03:55:39 EDT --- I'm not able to use this example either, as it uses arduino sdk configuration: $ cmake .. CMake Error at cmake/ArduinoToolchain.cmake:81 (message): Could not find Arduino SDK (set ARDUINO_SDK_PATH)! I checked the CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:61 which fails on your system. It just tries to compile simple: #ifdef __cplusplus # error "The CMAKE_C_COMPILER is set to a C++ compiler" #endif #if defined(__CLASSIC_C__) int main(argc, argv) int argc; char* argv[]; #else int main(int argc, char* argv[]) #endif { (void)argv; return argc-1; } and it worked here too. Also, I found that this error message (in distant past) was visible with seeing architecture: UNKNOWN!, flags 0x00000011: in avr-objdump output of libgcc, but again, the one we ship looks fine. --- Additional comment from Chris Evich on 2014-08-29 10:17:39 EDT --- Thanks for responding so quickly, sorry I am not much of an expert, I am *just* starting to grow out of the Arduino IDE "wheelchair" :D The "Arduino SDK" just comes from the standard 'arduino' package that we ship. Cmake just wants to find paths to the libraries. However it doesn't even get to using them as you've seen above. But I think you're reproducer is probably fine as well. Oh great, that's the test code, if I use same build commands from arduino-cmake it gives same error, so I don't need cmake or arduino stuff to reproduce: $ /usr/lib64/ccache/avr-gcc -g -Os -mcall-prologues -ffunction-sections -fdata-sections -o test.c.obj -c test.c $ /usr/lib64/ccache/avr-gcc -g -Os -mcall-prologues -ffunction-sections -fdata-sections -Wl,--gc-sections -lm test.c.obj -o test /usr/lib/gcc/avr/4.9.1/../../../../avr/bin/ld: skipping incompatible /usr/lib/gcc/avr/4.9.1/libgcc.a when searching for -lgcc /usr/lib/gcc/avr/4.9.1/../../../../avr/bin/ld: cannot find -lgcc collect2: error: ld returned 1 exit status I'm not sure how to use avr-objdump exactly, but playing with it I found: $ avr-objdump -f test.c.obj test.c.obj: file format elf32-avr architecture: avr, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000 $ avr-objdump -f /usr/lib/gcc/avr/4.9.1/libgcc.a In archive /usr/lib/gcc/avr/4.9.1/libgcc.a: _absvhi2.o: file format elf32-little architecture: UNKNOWN!, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000 _addvhi3.o: file format elf32-avr architecture: avr, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000 ...repeat for each object in archive... I didn't check the hundreds of others, but at least the first one shows that 'UNKNOWN!' arch. What can I look at next? --- Additional comment from Chris Evich on 2014-08-29 10:19:25 EDT --- FWIW: $ rpm -qf /usr/lib/gcc/avr/4.9.1/libgcc.a avr-gcc-4.9.1-2.fc21.x86_64 $ rpm -V avr-gcc-4.9.1-2.fc21.x86_64 ...nothing... --- Additional comment from Chris Evich on 2014-08-29 10:28:43 EDT --- All of the other ones seem to have this also: $ pwd /usr/lib/gcc/avr/4.9.1 [cevich@cevich 4.9.1]$ find -name libgcc.a | xargs -L 1 avr-objdump -f | grep -B 1 UNKNOWN _absvhi2.o: file format elf32-little architecture: UNKNOWN!, flags 0x00000011: -- _absvhi2.o: file format elf32-little architecture: UNKNOWN!, flags 0x00000011: -- _absvhi2.o: file format elf32-little architecture: UNKNOWN!, flags 0x00000011: -- ...repeat... What can I look at next that would help? --- Additional comment from Michal Hlavinka on 2014-08-29 12:16:11 EDT --- (In reply to Chris Evich from comment #6) > Oh great, that's the test code, if I use same build commands from > arduino-cmake it gives same error, so I don't need cmake or arduino stuff to > reproduce: > > $ /usr/lib64/ccache/avr-gcc -g -Os -mcall-prologues -ffunction-sections > -fdata-sections -o test.c.obj -c test.c You've used the code from comment #5 as test.c or what is the content? If I use that, it still works for me. (In reply to Chris Evich from comment #8) > All of the other ones seem to have this also: > > $ pwd > /usr/lib/gcc/avr/4.9.1 > [cevich@cevich 4.9.1]$ find -name libgcc.a | xargs -L 1 avr-objdump -f | > grep -B 1 UNKNOWN it prints nothing on my machine... I use Fedora 20 system with Fedora 21 avr-* packages. I will try again on Monday in virtual machine with freshly installed Fedora 21 and I will see if I can reproduce this. --- Additional comment from Michal Hlavinka on 2014-08-29 12:21:32 EDT --- OK, I just noticed that you use even newer packages than those I've built. I've downloaded the newer ones and I can reproduce this now. Seems that packages from mass rebuild (4.9.1-2) are crippled. 4.9.1-1 works fine.