build.log and emerge --info output will be attached.
Created attachment 256959 [details] build.log
Created attachment 256960 [details] emerge --info output
GCC(1) says: core2 Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. You don't have 64-bit extensions on an Intel Atom N270, so set -march= accordingly. Also, this has nothing to do with distcc.
> Also, this has nothing to do with distcc. Probably, that's not the case. 1. Please see an Intel's article that suggests -march=core2: http://software.intel.com/en-us/articles/getting-started-with-icc-for-the-mid/ Adding optimization flags to a compiler can boost the speed at which an application runs. When using GCC to compile, there are a few recommended flags to use: § -O2 or -O1: O2 flag optimizes for speed, while the -O1 flag optimizes for size § -msse3 § -march=core2 § -mfpmath=sse 2. taglib does compile without distcc, but with -march=core2. Also all the other packages on the system in question do. Anyway, if you still insist, I can reproduce the issue with -march=pentium4 or what would you like.
So you're cross-compiling with an amd64 distcc server, then?
Yes, I use an amd64 server to cross-compile for x86 in accordance with the guide http://www.gentoo.org/doc/en/cross-compiling-distcc.xml Then, according to the build.log attached, cmake fails to do some test compilation: /usr/lib/ccache/bin/gcc -march=core2 -mfpmath=sse -O2 -fomit-frame-pointer -pipe -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c /var/tmp/portage/media-libs/taglib-1.6.3/work/taglib-1.6.3_build/CMakeFiles/CMakeTmp/testCCompiler.c /usr/lib/ccache/bin/gcc -march=core2 -mfpmath=sse -O2 -fomit-frame-pointer -pipe -Wl,-O1 -Wl,--as-needed CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o cmTryCompileExec -rdynamic /usr/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../i686-pc-linux-gnu/bin/ld: i386:x86-64 architecture of input file `CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o' is incompatible with i386 output It seems some things are misinterpreted to be 64-bit. This also occures with some other packages using cmake. I'll provide the server-side distcc logs ASAP.
What if you turned off ccache just for once and kept distcc enabled? And does your distcc client have the proper wrapper and symlinks in /usr/lib/distcc/bin?
> And does your distcc client have the proper wrapper and symlinks in /usr/lib/distcc/bin? Thank you very much! That's is the point. After a distcc upgrade on the client, the symlinks have got overwritten, and now their target is plain distcc and not the CHOST-aware wrapper. Thus, the server calls its native compiler rather than the cross one. So, a workaround could be to add the directory containing those symlinks to CONFIG_PROTECT.
Maybe sys-devel/distcc could add /usr/lib/distcc/bin to the CONFIG_PROTECT variable itself?
I see. I guess that /usr/lib/distcc/bin/* should be generated by distcc-config(--update-wrapper or --update-masquerade?) instead of src_install.
It has always been a problem with those using distcc for cross-compiling in that the cc, c++, gcc and g++ links to a wrapper file are overwritten on distcc upgrades, giving faulty results after every upgrade unless the user is diligent in manually replacing them. It's extremely easy to miss and after struggling with it for quite some time (CONFIG_PROTECT just won't do it) I found a way to automate the process via /etc/portage/bashrc as documented at the bottom of this wiki page: https://wiki.gentoo.org/wiki/Distcc/Cross-Compiling Essentially this solved this bug and worked great for a year or so. But suddenly this wasn't working and I had faulty results again, traced to the links being replaced with distcc's default values. No matter which phase of the ebuild I trigger upon with the bashrc file the ebuild nukes them afterwards, making the effort all for nought (after portage-2.1.5 pkg_postinst should be the last thing executed, I have tried both that and pkg_postrm). And a new twist as well, not only does it replace the links, but removes the wrapper as well! It's not that the ebuild is doing anything wrong, but perhaps there is a way we can still make things sensible for distcc cross-compiling. It's easy enough even to rewrite the wrapper file from the bashrc code, if only it can be given the "last word". Thanks!
There is some new with recent versions of distcc: the contents of /usr/lib/distcc/bin is removed, and all manual wrappers are then deleted the wrapper described in the cross-distcc guide + additional links (for example I use crossdev through distcc with success). So now, I have, additionally to the initial problem (change the cc, c++, gcc and g++ links to the wrapper), re-create my cross-gcc links again and again.
