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.

Code:

---

gcc -print-search-dirs

---

Tried that. No dice. This gives me all the support programs, but not the "real" location of the binary. I guess I'll just have to stick with the approach `which gcc`.

Thanks anyways.

What's wrong with "whereis gcc"?

Code:

---

root@Slack:~# whereis gcc
gcc: /usr/bin/gcc /usr/lib/gcc /usr/X11R6/bin/gcc /usr/bin/X11/gcc /usr/X11/bin/gcc /usr/libexec/gcc /usr/man/man1/gcc.1.gz /usr/share/man/man1/gcc.1.gz /usr/X11/man/man1/gcc.1.gz
root@Slack:~# which gcc
/usr/bin/gcc

---

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.

Well, it's up to you but of those:

/usr/bin/gcc
/usr/lib/gcc
/usr/X11R6/bin/gcc
/usr/bin/X11/gcc
/usr/X11/bin/gcc
/usr/libexec/gcc
/usr/man/man1/gcc.1.gz
/usr/share/man/man1/gcc.1.gz
/usr/X11/man/man1/gcc.1.gz

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":

Code:

---

for x in `whereis -b gcc`; do if [ -f $x ]; then echo $x; fi; done

---

I get only one answer to that question ;)

and I get

Code:

---

root@Slack:~# for x in `whereis -b gcc`; do if [ -f $x ]; then echo $x; fi; done
/usr/bin/gcc
/usr/X11R6/bin/gcc
/usr/bin/X11/gcc
/usr/X11/bin/gcc

---

I also know that some of the projects the folks that _may_ download my scripts are using various native compilers (but I don't understand why -- I think it is a bad idea too).

Code:

---

$ file /usr/bin/gcc

---

If it is a symbolic link, then it tells where the real file is.

Is it safe to assume those X11 ones are not what you want (what are those anyway?)

Code:

---

for x in `whereis -b gcc`; do if [[ -f $x && $x != *X11* ]]; then echo $x; fi; done

---

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

Quote:

---

Originally Posted by MK27

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).

Ah. I would assume whereis uses the execution PATH, so it's output would also change. My point was that of the files returned, one of them must be gcc, and the others *should not be*.