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
Created attachment 194069 [details, diff] Patch to ebuild to fix CC issue This package is based on autotools, but ships a configure so old that passing --host= does not cause it to use a fully qualified gcc name. Rerunning autoconf after unpacking updates to a newer configure, which then uses a fully qualified gcc name. Since configure is overwritten by the autoconf run, I have dropped use of a patch that modified the resolver check in the configure script.
Well it has been almost a year so the patch doesn't work with the latest autoconf. I fixed this bug using the old good way by exporting the CC variable
(In reply to comment #2) > Well it has been almost a year so the patch doesn't work with the latest > autoconf. Thirteen months to the day, to be exact. Aside from the diagnostic that setting WANT_AUTOCONF=latest is no longer valid, calling autoconf seems to work fine. What error did you encounter when attempting to regenerate configure?
