When using crossdev to install binutils, gcc-avr and avr-libc with the command 'crossdev -t avr -s4', the resulting avr-gcc compiler has no libgcc.a for each of the sub-architectures of the AVR. By editing /usr/bin/crossdev and manually changing the -multilib flag to multilib, it is then possible to build various sub-architecture applications. An example of this would be trying to compile for the atmega1284p. avr-gcc (technically avr-ld, or collect2) complains 'skipping incompatible /usr/lib/gcc/avr/4.5.2/../../../../avr/lib/libc.a when searching for -lc'. This post by a user from July 10th, 2011 is exactly what is happening: http://forums.gentoo.org/viewtopic-t-886168-start-0.html Without multilib, the linker is not searching the sub-architecture based directories, such as avr51 for the atmega1284p. At this point, since I have it working by editing crossdev, I don't have any error output to paste. However, the basic steps were (before editing /usr/bin/crossdev) # crossdev -C avr # USE="-openmp" crossdev -t avr --l 1.7.0 --g 4.5.2 -s4 --without-headers # (compile and link an atmega1284p program, get a resulting failure basically as in the URL above) # crossdev -C avr # (edit /usr/bin/crossdev, enable multilib) # USE="-openmp" crossdev -t avr --l 1.7.0 --g 4.5.2 -s4 --without-headers # (successfully compile and link an atmega1284p program) Reproducible: Always
Unified diff output between the original crossdev and your version should be interesting enough to attach here.
# diff -u crossdev crossdev.jcw --- crossdev 2011-08-11 11:01:47.000000000 -0400 +++ crossdev.jcw 2011-08-11 11:00:53.000000000 -0400 @@ -653,7 +653,7 @@ set_keywords ${pkg} ${ver} set_use ${pkg} ${use} - set_use_force ${pkg} -multilib + set_use_force ${pkg} multilib set_links ${cat} ${pkg} set_env ${pkg} "${env}" } The crossdev is from sys-devel/crossdev-20110705. This change is only valid for the AVR architecture, which all I'm currently interested. I understand that it would likely break any other toolchain (msp430, hppa, etc) that requires -multilib.
that's not how multilib support works. your one line change will break many other targets.
(In reply to comment #3) > that's not how multilib support works. your one line change will break many > other targets. I'm FULLY aware of that. Read my comment: "This change is only valid for the AVR architecture, which all I'm currently interested. I understand that it would likely break any other toolchain (msp430, hppa, etc) that requires -multilib." I didn't say it was an appropriate fix for the crossdev tool, it was the fix ("hack" in modern parlance) that got the AVR cross-compiler working for me.
Created attachment 285553 [details, diff] crossdev-378387.patch added condition
Created attachment 285901 [details, diff] Forces and unmasks multilib for avr as target. Added support for profiles where multilib is masked by default as it was in my case (default/linux/x86/10.0/desktop as profile).
(In reply to comment #6) > Created attachment 285901 [details, diff] > Forces and unmasks multilib for avr as target. > > Added support for profiles where multilib is masked by default as it was in my > case (default/linux/x86/10.0/desktop as profile). I was hit by this one and spent several hours yesterday researching crossdev, understanding the multilib problem and finally understanding the interaction with profile. Huge thanks to Niklas for his patch - it showed me exactly where the problem is and works perfectly for me. It seems that the root cause for me was a long delayed update introducing -multilib into my profile use.force (profile is default/linux/x86/10.0/desktop) as I had not run crossdev for a long time before that and so the version I had previously run had not disabled multilib. Note my other PC is amd64 and so does not have multilib disabled in its profile - and is still working fine with its antique crossdev generated use flags!
post an actual test case for me to look at. referring to failures is not sufficient for me to check.
Confirming as a problem, and that forcing multilib fixes the issue. Testcase for me is using the generated toolchain with an Arduino microcontroller. The Arduino software is at http://www.arduino.cc/en/Main/software. The software here has several demos that call out to avr-gcc and avr-g++. Just pick one of the demos (eg - Blink), hit verify/compile, and watch it fail. If it's helpful, the specific call that fails appears to be calling avr-gcc as a linker, and specifying a particular chip to build for. I'll see if I can dig up the exact call, if it's helpful.
Here's the simplest testcase for you, requiring multilib support: $ echo "int main() {}" > test.c $ avr-gcc -mmcu=avr5 test.c Building the toolchain w/ multilib support, the compilation continues as expected. Without, the compile fails with the following error: /usr/libexec/gcc/avr/ld: cannot find crtm16.o: No such file or directory collect2: ld returned 1 exit status
The second patch above ("Forces and unmasks multilib for avr as target") works great and doesn't break non avr targets. What will it take to get this submitted?
As already said from Jess, T Paris and Richard the submitted patch from Niklas really works fine. It doesn't affect other architectures but only AVR devices, if you don't compile crossdev with multilib it won't work. The two lines of code submitted from T Paris are perfect if you want to reproduce avr-gcc behaviour when you compile for Atmel devices. I personally don't use Arduino because I prefer to write C code directly executed from my AVR devices, now I've a working environment with it (multilib enabled). I've: - downloaded patch file from Niklas comment, saved it under crossdev/files directory (created dir "files" for it, with current portage there're no patches to crossdev) - added to crossdev-20111118.ebuild these lines: inherit eutils (at the beginning of the file) src_compile() { # Fix AVR cross-compiling epatch "${FILESDIR}"/crossdev-378387_2.patch } - generated a new digest for my crosstool package ebuild /usr/portage/sys-devel/crossdev/crossdev-20111118.ebuild digest - emerged crosstool again (emerge crosstool) then as usual I've created a cross toolchain for AVR (crosstool -C avr; crosstool --target avr) Can someone please alter this package with the supplied patch and update bugfix as well ? let me know if I can make few tests for you Ben
The proposed solution does not work at all. Yes, the sketches compiles without errors, the upload is also done without problems, but when I tried the Examples AnalogReadSerial, DigitalReadSerial, BareMinimum and ASCIITable it wouldn't work. Does anyone have an idea how to solve this problem? My Linux is Gentoo amd64. I tried the proposed solution with the Uno, Mega2560 and with the Mega1280. USE="-openmp" crossdev --target avr --gcc 4.5.3-r2 --binutils 2.21.1-r1 --libc 1.7.1 -s4 --without-headers -------------------------------------------------------------------------------- * crossdev version: 20111221 * Host Portage ARCH: amd64 * Target Portage ARCH: * * Target System: avr * Stage: 4 (C/C++ compiler) * ABIs: default * binutils: binutils-2.21.1-r1 * gcc: gcc-4.5.3-r2 * libc: avr-libc-1.7.1
Gentoo x86 32bit inside a VMWare virtual machine (I'm using it only for developing software for Atmel devices). I cannot make tests on Arduino boards because I don't use them, I'm using ATMega 168, 328, 88, ATTiny but I've no problems with them (serial ports, PVM, ADC, ... all that stuff). AVR LibC is one of my needs also and it works nice without troubles. Is there anyone with Arduino boards to confirm it and help Henrique as well ? Ben
Niklas Patch works for me on 2 x86 machines with Arduino Uno (ATmega328) and Arduino Mega 2560 (ATmega2560) with: USE="-openmp" crossdev --target avr --gcc 4.6.2 --binutils 2.21.1 --libc 1.7.1 -s4 --without-headers
I already got to get all the boards worked. More details on the Arduino forum: http://arduino.cc/forum/index.php/topic,93672.0.html
*** This bug has been marked as a duplicate of bug 377039 ***
Created attachment 342282 [details, diff] patchfile for version 20120721