gcc ebuild installs config file into /etc/env.d/gcc (in my case, /etc/env.d/gcc/i686-pc-linux-gnu-3.3.3) that contains CC and CXX variables, defined as CC="gcc" and CXX="g++". These are the defaults picked by autoconf (and because there are /usr/bin/{cc,c++} links, by virtually any Unix build system), so it is pointless to set it (in this case, I realize it may be needed when switching compilers, although symlinks in /usr/bin would do as well). The problems arise when cross-compiling with autoconf-2.5: vasek@wintermute BUILD-msw $ ../configure --build=i586-linux --host=i586-mingw32 checking build system type... i586-pc-linux-gnu checking host system type... i586-pc-mingw32 checking target system type... i586-pc-mingw32 checking for i586-mingw32-gcc... gcc checking for C compiler default output file name... a.out As you can see, wrong compiler is picked, because CC is set. If CC is not set, autoconf is able to correctly determine the right executable: vasek@wintermute BUILD-msw $ CC= ../configure --build=i586-linux --host=i586-mingw32 checking build system type... i586-pc-linux-gnu checking host system type... i586-pc-mingw32 checking target system type... i586-pc-mingw32 checking for i586-mingw32-gcc... i586-mingw32-gcc checking for C compiler default output file name... a.exe The obvious fix would be to not set these variables unless _really_ needed. Reproducible: Always Steps to Reproduce:
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
