I'm filing this bug (from a template, mind you) because the ebuild I'm reporting it against failed to build once I removed my /usr/bin/{gcc,cc,c++,c99} binaries. This means that the ebuild is relying on gcc or cc as compiler, while it should use "$(tc-getCC)" so that user choices are respected, and cross-compiling works as intended. This usually comes down to one of these tasks: - use emake CC="$(tc-getCC)" for building, to ovewrite make's CC variable (defaults to "cc", some upstream rewrites it); - the above plus replacing explicit "gcc" (or similar) calls with $(CC) so that the variable is actually respected; - tc-export CC in src_compile before eventual econf. For C++, you'd have to replace CC with CXX everywhere above, of course. If your package is a special case on this, please let me know. Thanks, Diego
I can't reproduce this. I moved my /usr/bin/gcc and /usr/i686-pc-linux-gnu/gcc-bin/4.3.4/i686-pc-linux-gnu-gcc binaries (i added .test to their names). After that i did a quick: CC=i686-pc-linux-gnu-gcc.test ebuild odbtp-1.1.4.ebuild install and saw now problems with it. It just used the $CC i provided. Can you please give me a more detailed way to test this? I'm sure i misunderstood something here.
Reopening.
Created attachment 225751 [details] build.log build.log of odbtp-1.1.4 using 'gcc' instead of full compiler name, should be using 'x86_64-pc-linux-gnu-gcc' in my case.
(In reply to comment #0) > - tc-export CC in src_compile before eventual econf. And like Diego already said above, simple inherit toolchain-funcs and tc-export CC before econf solves the issue i.e. exporting the $CC to environment so econf grabs it
thanks for explaining this. I've added tc-export CC in CVS.
