Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 243872 - dev-lang/gpc: CC variable not respected
Summary: dev-lang/gpc: CC variable not respected
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: George Shapovalov (RETIRED)
Depends on:
Blocks: tc-directly
  Show dependency tree
Reported: 2008-10-24 17:30 UTC by Diego Elio Pettenò (RETIRED)
Modified: 2008-12-27 19:40 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Diego Elio Pettenò (RETIRED) gentoo-dev 2008-10-24 17:30:09 UTC
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.

Comment 1 George Shapovalov (RETIRED) gentoo-dev 2008-12-27 11:50:09 UTC
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.
Comment 2 Harald van Dijk (RETIRED) gentoo-dev 2008-12-27 12:18:23 UTC
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.
Comment 3 George Shapovalov (RETIRED) gentoo-dev 2008-12-27 13:46:56 UTC
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..
Comment 4 George Shapovalov (RETIRED) gentoo-dev 2008-12-27 13:49:23 UTC
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).
Comment 5 George Shapovalov (RETIRED) gentoo-dev 2008-12-27 14:08:41 UTC
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 :)).
Comment 6 Harald van Dijk (RETIRED) gentoo-dev 2008-12-27 19:40:57 UTC
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. :)