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
Well, this one is "yet another gcc frontend", so, technically, the best way would be to make it part of gcc (it does not requires any extra compiler properties, like Ada), like was done with D. However, last time I tried there were some issues. Plus this thing is hopelessly lagging behind (last release is based on 4.1 backend) and I doubt users will be much interested by ability to SLOT it. But thanks for reporting. One way or another I'll fix this.
As I recall, gpc already respected the CC variable, but didn't make it default to ${CHOST}-gcc. I ended up closing bug #243696 because of it and the lack of reply, but forgot to do so for the other bugs with the same issue, and now I'm no longer sure if gpc was one of them. George, could you please check this? If you remove /usr/bin/cc and /usr/bin/gcc, and then export CC as /usr/bin/${CHOST}-gcc, can you get gpc (re)installed? I'd try it myself but I'm running into another problem that makes gpc fail to configure (and I'll check what's causing that). You can recreate /usr/bin/cc and gcc afterwards using gcc-config.
Well, I am already in the middle of trying tc-export and it seems Ok so far. Is {CHOST}-gcc preferable to tc-export? It's a one-liner either way..
Oh, and that issue might be coming up at all only because this is based on the 3.4 gcc backend. Unfortunately this is the one we are stuck with. See bug #252323, that I just closed, for details (in short, the only alternative atm is 4.1 and that one shows performance regressions).
Well, tc-export works, so I am going to commit this fix. Please reopen the bug if you prefer the {CHOST}-gcc (just tell me why :)).
I meant there was nothing to change; this was a user problem. If CC was set properly, gpc already respected it. But tc-export doesn't hurt, so no complaints. :)