Summary: | sys-devel/crossdev-20110705: crossdev -t avr produces broken toolchain: cannot find crtm1280.o, skipping incompatible libm.a when searching for -lm | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Moon <triffid.hunter> |
Component: | [OLD] Unspecified | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | atzengin, da5id2001, earny, embedded, gentoo, jcwren, jm.beaune, kripton, lz1bgb, mail, niklashilcken, qbasicer, radek, vugluskr |
Priority: | Normal | ||
Version: | 10.1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=147155 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
gcc-4.5.2.ebuild with addition of gcc-005-constructor patch
gcc-005-constructor patch to save R20 in _ctors and _dtors crossdev-avrMultilib.patch |
Description
Michael Moon
2011-07-30 10:41:44 UTC
$ equery b crtm1280.o * Searching for crtm1280.o ... cross-avr/avr-libc-1.7.0 (/usr/avr/lib/avr51/crtm1280.o) cross-avr/avr-libc-1.7.0 (/usr/avr/lib/avr5/crtm1280.o) $ avr-gcc -Os -mmcu=atmega1280 -DF_CPU=16000000L -std=gnu99 -o mendel.elf mendel.o -lm -L /usr/avr/lib/avr51 /usr/libexec/gcc/avr/ld: cannot find crtm1280.o: No such file or directory /usr/libexec/gcc/avr/ld: skipping incompatible /usr/lib/gcc/avr/4.5.2/libgcc.a when searching for -lgcc /usr/libexec/gcc/avr/ld: cannot find -lgcc /usr/libexec/gcc/avr/ld: skipping incompatible /usr/lib/gcc/avr/4.5.2/libgcc.a when searching for -lgcc /usr/libexec/gcc/avr/ld: cannot find -lgcc collect2: ld returned 1 exit status $ ln -s /usr/avr/lib/avr51/crtm1280.o $ avr-gcc -Os -mmcu=atmega1280 -DF_CPU=16000000L -std=gnu99 -o mendel.elf mendel.o -lm -L /usr/avr/lib/avr51 /usr/libexec/gcc/avr/ld: skipping incompatible /usr/lib/gcc/avr/4.5.2/libgcc.a when searching for -lgcc /usr/libexec/gcc/avr/ld: cannot find -lgcc /usr/libexec/gcc/avr/ld: skipping incompatible /usr/lib/gcc/avr/4.5.2/libgcc.a when searching for -lgcc /usr/libexec/gcc/avr/ld: cannot find -lgcc collect2: ld returned 1 exit status $ equery b libgcc.a * Searching for libgcc.a ... cross-avr/gcc-4.5.2 (/usr/lib/gcc/avr/4.5.2/libgcc.a) sys-devel/gcc-4.4.5 (/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/libgcc.a) forcing the lib dir and symlinking the startup file into ./ seems to help, but I only have the one avr/libgcc.a! I read somewhere that this may happen when avr-gcc is a different version to system gcc so I passed --g 4.4.5 to crossdev. I also read that passing -v shows the full commandline passed to avr-ld. This showed that it's looking in current dir for crtm1280.o instead of /usr/avr/lib/$MCPU Symlinking that file into current dir gave this: $ avr-gcc -v -Os -mmcu=atmega1280 -DF_CPU=16000000L -std=gnu99 -o mendel.elf mendel.o Using built-in specs. Target: avr Configured with: /var/tmp/portage/cross-avr/gcc-4.4.5/work/gcc-4.4.5/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/avr/gcc-bin/4.4.5 --includedir=/usr/lib/gcc/avr/4.4.5/include --datadir=/usr/share/gcc-data/avr/4.4.5 --mandir=/usr/share/gcc-data/avr/4.4.5/man --infodir=/usr/share/gcc-data/avr/4.4.5/info --with-gxx-include-dir=/usr/lib/gcc/avr/4.4.5/include/g++-v4 --host=i686-pc-linux-gnu --target=avr --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/avr/4.4.5/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --disable-threads --disable-bootstrap --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.5 p1.3, pie-0.4.5' Thread model: single gcc version 4.4.5 (Gentoo 4.4.5 p1.3, pie-0.4.5) COMPILER_PATH=/usr/libexec/gcc/avr/4.4.5/:/usr/libexec/gcc/avr/4.4.5/:/usr/libexec/gcc/avr/:/usr/lib/gcc/avr/4.4.5/:/usr/lib/gcc/avr/ LIBRARY_PATH=/usr/lib/gcc/avr/4.4.5/:/usr/lib/gcc/avr/4.4.5/../../../../avr/lib/ COLLECT_GCC_OPTIONS='-g' '-Wall' '-Wstrict-prototypes' '-Os' '-ffunction-sections' '-finline-functions-called-once' '-mcall-prologues' '-mmcu=atmega1280' '-DF_CPU=16000000L' '-std=gnu99' '-funsigned-char' '-funsigned-bitfields' '-fpack-struct' '-fshort-enums' '-save-temps' '-o' 'mendel.elf' '-v' /usr/libexec/gcc/avr/ld -m avr5 -Tdata 0x800200 -o mendel.elf crtm1280.o -L/usr/lib/gcc/avr/4.4.5 -L/usr/lib/gcc/avr/4.4.5/../../../../avr/lib --as-needed --gc-sections mendel.o dda.o gcode_parse.o gcode_process.o timer.o temp.o sermsg.o dda_queue.o watchdog.o debug.o sersendf.o heater.o analog.o intercom.o pinio.o clock.o home.o crc.o delay.o serial.o -lm -lgcc -lc -lgcc heater.o: In function `heater_init': /home/triffid/Projects/Teacup_Firmware/heater.c:167: undefined reference to `__eewr_dword_m1280' /home/triffid/Projects/Teacup_Firmware/heater.c:98: undefined reference to `__eewr_dword_m1280' /home/triffid/Projects/Teacup_Firmware/heater.c:101: undefined reference to `__eewr_dword_m1280' /home/triffid/Projects/Teacup_Firmware/heater.c:101: undefined reference to `__eewr_word_m1280' /home/triffid/Projects/Teacup_Firmware/heater.c:101: undefined reference to `__eewr_word_m1280' /home/triffid/Projects/Teacup_Firmware/heater.c:157: undefined reference to `__eerd_dword_m1280' /home/triffid/Projects/Teacup_Firmware/heater.c:158: undefined reference to `__eerd_dword_m1280' /home/triffid/Projects/Teacup_Firmware/heater.c:159: undefined reference to `__eerd_dword_m1280' /home/triffid/Projects/Teacup_Firmware/heater.c:160: undefined reference to `__eerd_word_m1280' /home/triffid/Projects/Teacup_Firmware/heater.c:163: undefined reference to `__eerd_word_m1280' So apparently even with all that workaround, it still can't find stuff! If I add -L/usr/avr/lib/avr5 to that commandline, it compiles successfully and seems to work. Crossdev should be creating a toolchain that can work all this stuff out for itself! crossdev-20100814 installed a working avr-gcc-4.4.3, avr-binutils-2.20.1 and avr-libc-1.6.8 on an old install, but these exact same versions on my new install produce the above errors! Whatever's changed to cause this problem is outside these packages, perhaps portage tree or portage itself? This bug affects me too. Linking fails when it can't find crtm128rfa1.o which is installed to /usr/avr/lib/avr51/ folder by avr-libc. Avr toolchain used to work just fine few months ago but some updates had obviously caused it to not work any more and show this same error. I managed to get working toolchain back after downgrading crossdev to 20101011 and completely rebuilding the toolchain with that version. Crossdev versions 20110310(newest stable), 20110705 and 99999999 all produced not working toolchains. Versions I specified crossdev to build were avr-libc-1.7.0, avr-gcc-4.4.5 and binutils-2.20.1-r1 however that doesn't seem to have any effect in this bug. *** Bug 378517 has been marked as a duplicate of this bug. *** This affects me too. All my work has stopped just because of this. In my case, I face this on Arduino IDE. The crossdev version has nothing to do with this error. The real reason for this error is that gcc for avr needs to be compiled with multilib enabled in order to have a library path properly set. How to get a working avr toolchain on non-multilib systems: a) Unmerge the broken gcc: emerge --unmerge cross-avr/gcc b) In /usr/portage/eclass/toolchain.eclass search for gcc-library-configure() function, c) Change "--disable-multilib" into "--enable-multilib" in this function d) Scroll few lines down to the gcc-compiler-configure() function and do the same there, e) Run crossdev -t avr to compile cross gcc again. This worked for me on 32-bit x86 Gentoo. Note that this is a terrible hack. Be sure to resync or undo the changes to toolchain.eclass later so you don't compile native gcc with multilib enabled by mistake. In addition to gcc workaround from my previous comment binutils, as of version 2.21.1, also needs to have ldscripts symlinked in order to find them. To do that go to /usr/i686-pc-linux-gnu/avr/binutils-bin/2.21.1/ (where i686 is host arch and 2.21.1 is binutils version) and execute "ln -s ../../lib/ldscripts ldscripts" (In reply to comment #7) > The crossdev version has nothing to do with this error. > > The real reason for this error is that gcc for avr needs to be compiled with > multilib enabled in order to have a library path properly set. Doesn't work for me. I'm using amd64, mutilib enabled. Masking >sys-devel/crossdev-20101011 works. So maybe there are 2 bugs: one on x86 (gcc) and one on amd64 (crossdev). Because on my x86 any crossdev downgrade doesn't result in a working toolchain. I have just tested on amd64 and can confirm that, out of the box, crossdev-20110819 does not work, but sys-devel/crossdev-20101011 does. However, if I comment out "set_use_force ${pkg} -multilib" in crossdev-20110819 it does produce a working toolchain. On my system, editing toolchain.eclass gives the same effect (working toolchain). Hopefully, when https://bugs.gentoo.org/show_bug.cgi?id=378387 is fixed it will fix this one, too. post an actual test case for me to look at. posting command lines that rely on source files that don't exist isn't sufficient. something like: echo 'main(){}' | avr-gcc -x c - ..... $ echo 'main(){}' | avr-gcc -mmcu=atmega328p -x c - /usr/libexec/gcc/avr/ld: cannot find crtm328p.o: No such file or directory $ ln -s /usr/avr/lib/avr5/crtm328p.o ./ $ echo 'main(){}' | avr-gcc -mmcu=atmega328p -x c - -lm $ ls a.out a.out so apparently somewhere in all my stuffing around with this, the incompatible libraries thing has resolved itself, but it still isn't looking for crt[cpu].o in the right spot (In reply to comment #12) > post an actual test case for me to look at. posting command lines that rely on > source files that don't exist isn't sufficient. a) Be on amd64, b) emerge --unmerge crossdev cross-avr/gcc c) emerge crossdev [installs 20111011] d) crossdev -t avr [note that you have to have hardened USE flag unset or gcc fails to build] e) echo 'main(){}' | avr-gcc -x c - -mmcu=atmega2561 Result is: /usr/libexec/gcc/avr/ld: cannot find crtm2561.o: No such file or directory /usr/libexec/gcc/avr/ld: skipping incompatible /usr/lib/gcc/avr/4.5.3/libgcc.a when searching for -lgcc /usr/libexec/gcc/avr/ld: cannot find -lgcc /usr/libexec/gcc/avr/ld: skipping incompatible /usr/lib/gcc/avr/4.5.3/../../../../avr/lib/libc.a when searching for -lc /usr/libexec/gcc/avr/ld: cannot find -lc /usr/libexec/gcc/avr/ld: skipping incompatible /usr/lib/gcc/avr/4.5.3/libgcc.a when searching for -lgcc /usr/libexec/gcc/avr/ld: cannot find -lgcc collect2: ld returned 1 exit status Will check what happens on non-multilib x86 host tomorrow. Enabling multilib and using "non-stable" versions like --gcc 4.5.1-r1 --binutils 2.21.1 --libc 1.7.1 , compiles and works fine. BUT!, it creates faulty binaries for serial libraries for Arduino. I have tried both ATMEL toolchain and crossdev. First enable multilib from eclass, Then USE="-openmp" crossdev --target avr --gcc 4.5.1-r1 --binutils 2.21.1 --libc 1.7.1 -s4 --without-headers ln -s /usr/avr/lib/avr6/crtm2560.o /usr/avr/lib/crtm2560.o ln -s /usr/avr/lib/avr6/crtm2561.o /usr/avr/lib/crtm2561.o ln -s /usr/i686-pc-linux-gnu/avr/lib/ldscripts /usr/avr/lib/ldscripts disable multilib again. In this configuration delay.h has problem. Add #include <math.h> to fix it. This configuration seems working fine and compiles fine, but actually the binary created won't work. Forgot to say, ATMEL toolchain works like a charm. No problem with it. (In reply to comment #14) > Will check what happens on non-multilib x86 host tomorrow. The same happens on non-multilib x86. avr-g++ produces non-working binaries for me too, after clobbering everything else into submission. Not just arduino libs, but other C++ avr projects as well. I'm not familiar enough with C++ to craft even a simple test case for avr, anyone care to write a hello world in C++ and see what happens? (In reply to comment #15) > This configuration seems working fine and compiles fine, but actually the > binary created won't work. Which -mmcu are you using? I my case, after emerging with multilib USE flag on to get crts resulting toolchain does produce working binaries (including serial port baudrate calculation), at least for -mmcu=atmega2561. I've tried with both -mmcu=atmega1280 and -mmcu=atmega328p since those are the chips I have. The toolchain from my old install, and binary toolchains from non-gentoo users both compile the exact same code to a working binary. (In reply to comment #19) > Which -mmcu are you using? > > I my case, after emerging with multilib USE flag on to get crts resulting > toolchain does produce working binaries (including serial port baudrate > calculation), at least for -mmcu=atmega2561. Tried for atmega2560. In my case crossdev created environment produces faulty binary. Atmel toolchain produces working binary for exactly the same code. So(In reply to comment #20) > I've tried with both -mmcu=atmega1280 and -mmcu=atmega328p since those are the > chips I have. The toolchain from my old install, and binary toolchains from > non-gentoo users both compile the exact same code to a working binary. So, could you please post the smallest code fragment which doesn't work when compiled by Gentoo cross-gcc, but does work when compiled by Atmel gcc? I'm assuming that it does compile and link in the first place. In my case, I could only give an example on arduino. This is the shortest code which compiled fine and produce a working binary by Atmel toolchain, but a non-working binary by Gentoo cross gcc. void setup() { // initialize serial communications at 9600 bps: Serial.begin(9600); Serial.print("Hello"); } void loop() { } If I try to build my old simple project the compiler are generated : avr-gcc -Wl,-Map,labelrollm8.out.map -lm -mmcu=atmega8 -o labelrollm8.out main.o timers.o /usr/libexec/gcc/avr/ld: cannot find crtm8.o: No such file or directory collect2: ld returned 1 exit status make: *** [labelrollm8.out] Error 1 I try to look deep and add de verbouse comand: $ avr-gcc -v -Wl,-Map,labelrollm8.out.map -lm -mmcu=atmega8 -o labelrollm8.out main.o timers.o Using built-in specs. COLLECT_GCC=/usr/i686-pc-linux-gnu/avr/gcc-bin/4.5.3/avr-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.5.3/lto-wrapper Target: avr Configured with: /var/tmp/portage/cross-avr/gcc-4.5.3-r1/work/gcc-4.5.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/avr/gcc-bin/4.5.3 --includedir=/usr/lib/gcc/avr/4.5.3/include --datadir=/usr/share/gcc-data/avr/4.5.3 --mandir=/usr/share/gcc-data/avr/4.5.3/man --infodir=/usr/share/gcc-data/avr/4.5.3/info --with-gxx-include-dir=/usr/lib/gcc/avr/4.5.3/include/g++-v4 --host=i686-pc-linux-gnu --target=avr --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/avr/4.5.3/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --disable-threads --disable-bootstrap --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r1 p1.0, pie-0.4.5' Thread model: single gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) COMPILER_PATH=/usr/libexec/gcc/avr/4.5.3/:/usr/libexec/gcc/avr/4.5.3/:/usr/libexec/gcc/avr/:/usr/lib/gcc/avr/4.5.3/:/usr/lib/gcc/avr/ LIBRARY_PATH=/usr/lib/gcc/avr/4.5.3/:/usr/lib/gcc/avr/4.5.3/../../../../avr/lib/ COLLECT_GCC_OPTIONS='-v' '-mmcu=atmega8' '-o' 'labelrollm8.out' /usr/libexec/gcc/avr/4.5.3/collect2 -m avr4 -o labelrollm8.out crtm8.o -L/usr/lib/gcc/avr/4.5.3 -L/usr/lib/gcc/avr/4.5.3/../../../../avr/lib -Map labelrollm8.out.map -lm main.o timers.o -lgcc -lc -lgcc /usr/libexec/gcc/avr/ld: cannot find crtm8.o: No such file or directory collect2: ld returned 1 exit status The fail are during the linking the project with exact architecture. If I add the verbose command to linker I acheve: $ /usr/libexec/gcc/avr/4.5.3/collect2 -verbose -m avr4 -o labelrollm8.out crtm8.o -L/usr/lib/gcc/avr/4.5.3 -L/usr/lib/gcc/avr/4.5.3/../../../../avr/lib -Map labelrollm8.out.map -lm main.o timers.o -lgcc -lc -lgcc GNU ld (GNU Binutils) 2.21.1 Supported emulations: avr2 avr1 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 opened script file /usr/i686-pc-linux-gnu/avr/binutils-bin/2.21.1/../../../../avr/lib/ldscripts/avr4.x using external linker script: ================================================== /* Default linker script, for normal executables */ OUTPUT_FORMAT("elf32-avr","elf32-avr","elf32-avr") OUTPUT_ARCH(avr:4) MEMORY { ------------------snip----------------------------- .debug_macinfo 0 : { *(.debug_macinfo) } } ================================================== attempt to open crtm8.o failed attempt to open /usr/lib/gcc/avr/4.5.3/libm.so failed attempt to open /usr/lib/gcc/avr/4.5.3/libm.a failed attempt to open /usr/lib/gcc/avr/4.5.3/../../../../avr/lib/libm.so failed attempt to open /usr/lib/gcc/avr/4.5.3/../../../../avr/lib/libm.a succeeded attempt to open main.o succeeded main.o attempt to open timers.o succeeded timers.o attempt to open /usr/lib/gcc/avr/4.5.3/libgcc.so failed attempt to open /usr/lib/gcc/avr/4.5.3/libgcc.a succeeded (/usr/lib/gcc/avr/4.5.3/libgcc.a)_copy_data.o (/usr/lib/gcc/avr/4.5.3/libgcc.a)_clear_bss.o attempt to open /usr/lib/gcc/avr/4.5.3/libc.so failed attempt to open /usr/lib/gcc/avr/4.5.3/libc.a failed attempt to open /usr/lib/gcc/avr/4.5.3/../../../../avr/lib/libc.so failed attempt to open /usr/lib/gcc/avr/4.5.3/../../../../avr/lib/libc.a succeeded attempt to open /usr/lib/gcc/avr/4.5.3/libgcc.so failed attempt to open /usr/lib/gcc/avr/4.5.3/libgcc.a succeeded /usr/bin/avr-ld: cannot find crtm8.o: No such file or directory collect2: ld returned 1 exit status Probably someting wrong in compilation and some path because if I put the crtm8.o in source directory all files are compiled and linked corectly. But that are incredible hard to change each time and replace the file in same source for diferent architectures. Some ideas? *** Bug 393081 has been marked as a duplicate of this bug. *** (In reply to comment #7) > The crossdev version has nothing to do with this error. > > The real reason for this error is that gcc for avr needs to be compiled with > multilib enabled in order to have a library path properly set. > > How to get a working avr toolchain on non-multilib systems: > a) Unmerge the broken gcc: emerge --unmerge cross-avr/gcc > b) In /usr/portage/eclass/toolchain.eclass search for gcc-library-configure() > function, > c) Change "--disable-multilib" into "--enable-multilib" in this function > d) Scroll few lines down to the gcc-compiler-configure() function and do the > same > there, > e) Run crossdev -t avr to compile cross gcc again. > > This worked for me on 32-bit x86 Gentoo. > > Note that this is a terrible hack. > Be sure to resync or undo the changes to toolchain.eclass later so you don't > compile native gcc with multilib enabled by mistake. Apparently the structure of toolchain.eclass has changed since this was originallu posted. In version "v 1.489 2011/12/03 20:45:45 vapier" of the file, I made the following changes starting at line 1004: gcc-multilib-configure() { # if multilib is disabled, get out quick! #if ! is_multilib ; then #confgcc+=" --disable-multilib" #return #else confgcc+=" --enable-multilib" #fi (basically commenting everything out except the one line). In addition, /usr/bin/crossdev from crossdev-20111018, line 457 needs the following change. -GUSE_DISABLE_STAGE_1="${GUSE_DISABLE} -fortran nocxx -openmp" +GUSE_DISABLE_STAGE_1="${GUSE_DISABLE} -fortran nocxx -cxx -openmp" Tthe following commands build a working toolchain with gcc-4.5.2, binutils-2.22 and avr-libc-1.7.0 on an x86 machine: # crossdev -C avr # cp gcc-4.5.2.ebuild /usr/portage/sys-devel/gcc # cp gcc-005-constructor.patch /usr/portage/sys-devel/gcc/files # ebuild /usr/portage/sys-devel/gcc/gcc-4.5.2.ebuild manifest # ln -s /usr/lib/binutils/avr/2.22/ldscripts /usr/i686-pc-linux-gnu/avr/binutils-bin/2.22/ldscripts # USE="-openmp" crossdev -t avr --l 1.7.0 --g 4.5.2 -s4 --without-headers The gcc-005-constructor patch is necessary for AVR cores supporting the RAMPZ instruction. See attachments for the above two files that are copied. gcc-4.5.2.ebuild has the addition of the following after line 45: [[ ${CTARGET} == *avr* ]] && epatch "${FILESDIR}"/gcc-005-constructor.patch There's probably some more elegant and correct way to enable multilib in the toolchain.eclass using a conditional based on the target. Since this was actually holding me up from producing an AVR-based deliverable for a client, I didn't have time to figure out how to properly correct it. It's a nasty brute-force approach, and the toolchain.ebuild changes should be removed after a successful build, as it's likely it will break something it shouldn't. Created attachment 294747 [details]
gcc-4.5.2.ebuild with addition of gcc-005-constructor patch
This is the gcc-4.5.2.ebuild file with the single line added at line 45 to apply the gcc-005-constructor patch for AVR processors.
Created attachment 294749 [details, diff]
gcc-005-constructor patch to save R20 in _ctors and _dtors
This patch causes R20 to be saved in the _ctors and _dtors functions. On AVR cores with the RAMPZ instruction, the compiler will produce non-functional code without this patch.
*** Bug 378387 has been marked as a duplicate of this bug. *** Created attachment 304037 [details, diff]
crossdev-avrMultilib.patch
I attached a patch which fixes this problem by enabling multilib only for the avr target. The gcc constructor problems and patch should really be in a separate bug report. *** Bug 429994 has been marked as a duplicate of this bug. *** Comment on attachment 294747 [details]
gcc-4.5.2.ebuild with addition of gcc-005-constructor patch
not relevant to this bug ...
Comment on attachment 294749 [details, diff]
gcc-005-constructor patch to save R20 in _ctors and _dtors
not relevant to this bug ...
|