Compiling the helloworld.c example inside scratchbox will fail for ARM target. Reproducible: Always Steps to Reproduce: 1. Install scratchbox components (not all may be necessary to setup environment) emerge -v scratchbox scratchbox-devkit-apt-https scratchbox-devkit-debian scratchbox-devkit-doctools scratchbox-devkit-perl scratchbox-devkit-qemu scratchbox-toolchain-cs2007q3-glibc2_5 scratchbox-devkit-git scratchbox-devkit-svn 2.Try ./compilers/cs2007q3-glibc2.5-i486/bin/i486-pc-linux-gnu-gcc packages/hello.c -o /tmp/helloX86 This should compile and run. 3.Try ./compilers/cs2007q3-glibc2.5-arm7/bin/arm-none-linux-gnueabi-gcc packages/hello.c -o /tmp/helloArm Actual Results: Step 3 above fails with: /opt/scratchbox/compilers/cs2007q3-glibc2.5-arm7/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /opt/scratchbox/compilers/cs2007q3-glibc2.5-arm7/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/libgcc.a when searching for -lgcc /opt/scratchbox/compilers/cs2007q3-glibc2.5-arm7/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find -lgcc Expected Results: Should compile and run as in Step 2 for X86 target. This problem is reproducible when inside the scratchbox environment as well. If the scratchbox tools are installed manually, the example helloworld.c will compile and run for both targets.
The problem would appear to be within the scratchbox-toolchain-cs2007q3-glibc2_5 ebuild. This is stripping the files during install (presumably with an x86 application), which is messing up the ARM binaries/libraries. Adding RESTRICT="strip binchecks" to the ebuild fixes the issue here.
(In reply to comment #1) > Adding RESTRICT="strip binchecks" to the ebuild fixes the issue here. > I can confirm that this does fix the problem.
Mr Flameeyes decided it would be funny to remove the RESTRICT line without filing a bug or even trying to see if it actually breaks anything. I'm restoring it with a big fat comment...
You have been warned *especially* about *not using binchecks*. Thank you for *breaking again QA policies on that regard*.
Restrict stripping is fine here and should fixed the issue itself. Binchecks restrictions on the other hand should never EVER be used in something that installs ELF binaries. Let me cite the manpage: binchecks --------- Disable all QA checks for binaries. This should ONLY be used in packages for which binary checks make no sense (linux-headers and ker nel-sources, for example, can safely be skipped since they have no binaries). If the binary checks need to be skipped for other reasons (such as proprietary binaries), see the QA CONTROL VARIABLES section for more specific exemptions. So you only disable ALL qa warnings and nothing else. Warnings is the word here, not some removal of something magical from your package but just the warning that something is going wrong. If you feel like the packages are doing it correctly and qa warning is wrong then you can override that with QA_whatsoever variables that can be found in (man 5 ebuild). I note that user reported that something fixes the issue, i wonder if you tried the "fix" without the binchecks at all or just commited it in... (because here it really needs only that strip...) I agree that Diego removed wrongly the strip, but since you had wrong bincheck there from the starter and no documented reason why you restrict stuff there is quite good conclusion from that -> it is not required. (in theory it might be documented in changelog, but i don't see such text there nor in the cvs log for the package)
it'D be nice to leave something working in portage (arm binaries cannot be compiled and/or run atm .. i duno about strip/bincheck though ;)
The reason I disabled binchecks is that they take a long long long time on this package. And since this is a binary package, they are entirely useless. All they do in this case is to make the users miserable. That said, the package should work with RESTRICT=strip Are you sure it's still broken ? It works here for me.
that is simply not true. there are binary checks that will work regardless of the package being built from source. if your package installs binaries, you must not restrict bincheck. this is a bug in your ebuild an QA should fix it for you.
As I see it there is nothing left to discuss on this bug
