I noticed some day ago that when compiling linuxdcpp scons complained about CXX not being set. After some trial and error I realized that Portage does not set neither CC nor CXX env-vars, and hanging a bit on IRC ssuominen confirmed that the ebuild would need to "tc-export CXX" to get the CXX env var correctly set. What I do not get is why this is needed to begin with. As I have understood it, econf, cmake-utils.eclass and games.eclass does tc-export, but that leaves every other package that does not use mentioned methods to tc-export every needed variable themselves or they are broken (if they compile something). It feels like code duplication between ebuilds, and also a point of breakage for cross-compilation (what if an ebuild maintainer misses to specify a needed variable, out of the 16 or so variables that tc-export in toolchain-funcs.eclass handles?). So is there a reason why the Package manager cannot export these variables or at least the most common ones? Reproducible: Always Steps to Reproduce:
tc-export is only there for packages that dont respect the env vars themselves already. it isnt the business of the PM to break down the CTARGET/CHOST logic and come up with appropriate CC/CXX/etc... values. in other words, you're proposing we integrate toolchain-funcs.eclass into every PM which sounds like a bad idea. i dont see this being a problem that needs addressing at the PM level.
(In reply to comment #1) > tc-export is only there for packages that dont respect the env vars themselves > already. I try to parse this, and I fail to understand. Currently if I do a ebuild with just a src_compile() { echo "${CC}" "${CXX}" } and run "ebuild test-1.ebuild compile" I get a empty line, unless I specify CC and CXX in my own env, then portage picks this up. Is this the env vars you are talking about (i.e. if the package uses scons and you do not have "tc-export CC CXX" then what you have in your .bashrc should be used)? Or in other words every ebuild should themselves specify tc-export unless they use a eclass that already do this (else the outcome of the merge is hard-predicted)?
*** Bug 435786 has been marked as a duplicate of this bug. ***
*** Bug 408693 has been marked as a duplicate of this bug. ***
(In reply to SpanKY from comment #1) > tc-export is only there for packages that dont respect the env vars > themselves already. You are running on assumptions here. Indeed, most of GNU configure scripts default to using ${CHOST}-gcc but that isn't always true. So we end up somewhere near 'you need to export CC unless some logic in configure always comes up with our preferred CC'. It should be noted that autoconf supports overriding the compiler search list in AC_PROG_CC (AC_PROG_CXX). Then, some projects actually prefer clang over gcc, and then your assumption falls apart and we need to export CC. I think it would be good for consistency to have at least CC and CXX exported everywhere. As far as I'm concerned, the default values may come from profiles much like CFLAGS do.
I am not sure if this could be reviewed for the next eapi :/
If the values get set in profiles, no PMS change would be necessary.
To be honest, this is really a configuration/profile problem and not PMS. PMS doesn't tell anything to set CFLAGS, LDFLAGS etc. -- it's set by profiles and default configs. I think CC, CXX, etc. should be covered the same way.
(In reply to Michał Górny from comment #8) > To be honest, this is really a configuration/profile problem and not PMS. > PMS doesn't tell anything to set CFLAGS, LDFLAGS etc. -- it's set by > profiles and default configs. I think CC, CXX, etc. should be covered the > same way. Closing.
