Determine the location of gcc (using gcc)

This is a discussion on Determine the location of gcc (using gcc) within the Linux Programming forums, part of the Platform Specific Boards category; I was looking through a couple of configure scripts attempting to glean the way "they" do it, but failed. Also, ...

Determine the location of gcc (using gcc)

I was looking through a couple of configure scripts attempting to glean the way "they" do it, but failed. Also, looking through the man pages doesn't help -- there is just too much information to read the whole thing (and I'm VERY lazy). Google -- I must not have the right phrase 'case I get all kinds of strange and wonderfully useless stuff.

The question: aside from using CC=`which gcc`, is there a way to have gcc report the "real" location of itself. For example, when I build a cross compiler, I often link the files to something less awful to execute -- as the names of the real file get quite lengthy. So, I have a make system (that I wrote) and I want to use the native compiler to cross build one of the programs. That is to say, in the top of the make file I have something like:

CROSS_COMPILE ?= a_reall_long_path_to_the_gcc_string-

but I want to fake a cross build by supplying the path to gcc at the make call, like:

make CROSS_COMPILE=/usr/bin/

as my gcc sits in /usr/bin. So, configure scripts appear to do this some really nifty way -- and I want to know how too.

That returns too much. In my scripts I muck about with PATH so, these may not work for me. So, if I have a $CC set, I could run $CC with a command line param that would give me the real location of the binary -- the location that the binary was compiled to. This would mean that I would know the real path to the rest of the compile tools (not the gcc support tools, but binutils) as these are _supposed_ to be homed to the same location.

Most of them can be eliminated just because they are not in a /bin directory, which going by the Linux Filesystem standard gcc should be in a /bin. In fact, you can eliminate most of those just by using "whereis -b gcc" -- then if you eliminate the ones that are actually directories named "gcc":

There should only be ONE gcc in path, otherwise someone has done something silly.

In the build that I'm working with, the PATH is changed in order to compile a temporary tool-chain linked against a temporary library that has uber specific includes/optimizations for building a third tool-chain. BUT, I need to know the path to the real gcc so that I can run a non-sysroot-ed program that would be executed in a completely separate thread -- with _that_ PATH being a more normal PATH.

What I'm attempting to do is do a 6 stage build for an embedded file system, fully configured by the HOST machine, however, there are utilities that are self-installing that need to install before the last stage of the build is complete. This means that I have to build these utilities twice, force the install of the utilities (via the native build), then copy over the binaries with the cross build.

The scripts are really ugly -- I hope no one ever has to manipulate this suckers or they'll be really ill with me.

Hmm, now that I've read this something has just sprang to mind. . . I could always rebuild the original PATH via sourcing /etc/profile -- which _SHOULD_ rebuild the path and only effect the current thread (and since I'm the last one in that thread, that's okay).