Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 378387 - sys-devel/crossdev - avr multilib support
Summary: sys-devel/crossdev - avr multilib support
Status: RESOLVED DUPLICATE of bug 377039
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: Other Linux
: Normal normal with 2 votes (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-08 19:27 UTC by J.C. Wren
Modified: 2013-03-16 16:10 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
crossdev-378387.patch (crossdev-378387.patch,770 bytes, patch)
2011-09-04 21:36 UTC, Ilya Dmitrichenko
Details | Diff
Forces and unmasks multilib for avr as target. (crossdev-378387_2.patch,1.94 KB, patch)
2011-09-08 23:38 UTC, Niklas Hilcken
Details | Diff
patchfile for version 20120721 (crossdev-378387_20120721.patch,499 bytes, patch)
2013-03-16 16:10 UTC, Thomas Kohler
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description J.C. Wren 2011-08-08 19:27:27 UTC
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
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2011-08-11 14:57:28 UTC
Unified diff output between the original crossdev and your version should be interesting enough to attach here.
Comment 2 J.C. Wren 2011-08-11 15:05:44 UTC
# 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.
Comment 3 SpanKY gentoo-dev 2011-08-14 20:28:25 UTC
that's not how multilib support works.  your one line change will break many other targets.
Comment 4 J.C. Wren 2011-08-15 15:11:53 UTC
(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.
Comment 5 Ilya Dmitrichenko 2011-09-04 21:36:17 UTC
Created attachment 285553 [details, diff]
crossdev-378387.patch

added condition
Comment 6 Niklas Hilcken 2011-09-08 23:38:00 UTC
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).
Comment 7 Richard Kenney 2011-10-10 20:17:22 UTC
(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!
Comment 8 SpanKY gentoo-dev 2011-10-11 22:26:54 UTC
post an actual test case for me to look at.  referring to failures is not sufficient for me to check.
Comment 9 T Parys 2011-12-21 23:25:40 UTC
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.
Comment 10 T Parys 2011-12-23 22:48:36 UTC
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
Comment 11 Jess Haas 2012-01-03 20:27:42 UTC
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?
Comment 12 Andrea (Ben) Benini 2012-01-05 17:04:40 UTC
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
Comment 13 Henrique Dias 2012-02-27 11:57:02 UTC
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
Comment 14 Andrea (Ben) Benini 2012-02-27 13:30:50 UTC
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
Comment 15 Roland "Robelix" Obermayer 2012-02-27 13:56:47 UTC
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
Comment 16 Henrique Dias 2012-02-27 20:59:55 UTC
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
Comment 17 SpanKY gentoo-dev 2012-03-02 19:04:13 UTC

*** This bug has been marked as a duplicate of bug 377039 ***
Comment 18 Thomas Kohler 2013-03-16 16:10:09 UTC
Created attachment 342282 [details, diff]
patchfile for version 20120721