Summary: | gcc ebuild's setting of CC and CXX breaks cross-compilers | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Vaclav Slavik <vslavik> |
Component: | [OLD] Core system | Assignee: | Please assign to toolchain <gcc-porting> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ciaran.mccreesh, solar |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Vaclav Slavik
2004-03-15 01:24:21 UTC
when i cross compile with portage i override CHOST, CC, CXX, and CBUILD and have no problems usually *** This bug has been marked as a duplicate of 18034 *** > when i cross compile with portage i override CHOST, CC, CXX, and CBUILD and > have no problems usually That's the very point -- you *have* to override these settings, otherwise nothing works. On normal systems (and for that matter, any other distro), you don't have to. Once again, there's no reason to set these variables to their normal values, as explained in my report, so why is Gentoo unnecessarily causing problems by doing it? I know I can workaround it by (un)setting the variables, but the real question is why does Gentoo make development environment more complicated, if it can be easily fixed? > *** This bug has been marked as a duplicate of 18034 *** Huh? There's *no* relation between the two bugs that I could see. #18034 deals with making cross-compiler ebuilds, which is something completely different. The bug I reported here is that Gentoo stays in user's ways because *native* compiler ebuild breaks the environment for cross-compiling -- either via a cross-compiler installed using an ebuild or compiled from sources w/o Portage's help, it doesn't matter. Sorry if that wasn't clear from the report. Let me reiterate that on properly-configured system, you don't have to have CC and CXX set, autoconf will detect the right compiler itself (even if cross-compiling, the --host switch is sufficient). Setting CC and CXX makes sense only if you want to use nondefault compiler, e.g. when cross-compiling with gcc 2.95 instead of 3.3 as in CC=i586-linux-gcc-2.95 ./configure --build=i586-linux --host=i586-mingw32 -- and it should be left to the user to do so. Vaclav, Got patches? Done testing? (>=600 packages would be a good test 'emerge -e world') greped the portage tree to see what depends on C{C,XX,...} being set? > Got patches? No -- there's hardly any point in making a patch unless Gentoo developers in charge of gcc agree it's a problem, is there? > Done testing? I commented-out the variables when I filed the bug and am updating my system daily without any problems ever since (~6 weeks now). Vaclav, I'm not 100% sure on this but I'm assuming it's set mainly for the benefit of icc users in order to be able to take advantage of gcc-config support. You may also want to take a look at /usr/portage/eclass/gcc.eclass and offer some suggestions on what to do if CC= is not set. Actually from a quick two second look I can see why we depend on this. ive been slowly fixing the ebuilds that refer to $CC directly to use the gcc.eclass SpanKY it looks like the gcc.eclass directly will use/set CC=gcc in get-CC. Then if no CC is set it looks like the ${CC} -dumpversion would break ;/ no, it wont, and that's the point ;) if [ "${WANT_GCC_3}" = "yes" -o -z "${CC}" ] ; then local CC="gcc" if [ "$(${CC} -dumpversion | cut -f1 -d.)" -ne 3 ] && \ [ "${WANT_GCC_3}" = "yes" ] Sorry you are absolutely correct. -n != -z :) Off Topic Note: We can probably save end users a few nanoseconds and resources by cutting down on a few of those execve() calls for the | cut -d. -f1 or -f3 when using -dumpversion in that .eclass Consider the following example. CCVER=1.2.3 ; echo ${CCVER/.*/} ; echo ${CCVER/*./} No idea how to get the middle index in pure bash ;/ perhaps even the logic could be cleaned up in that function a bit ... it looks like it wont 'work' if using a gentoo-1.0 system (gcc-2.x based) and CC is unset ... but i dunno for sure ;) perhaps doing something like this: getver() { local oldifs="${IFS}" local idx="${1}" IFS="." set -- ${2} echo ${!idx} export IFS="${oldifs}" } getver 1 2.3.4 = 2 getver 2 2.3.4 = 3 getver 3 2.3.4 = 4 i just wrote this without testing so maybe it'll work ... How're we differentiating between CC, TARGETCC and HOSTCC? ok, i fixed this already ... thought i closed the bug though ... as for hostcc and all that, see toolchain-funcs.eclass |