1

In the sake of automatically-detecting native GCC installation from within a program, I would like to get the current path to gcc.exe or its root folder. But when I type gcc -print-prog-name=gcc it simply prints back gcc which is obviously not what I was expecting.

How do I use gcc or other components supposedly installed on the system alongside gcc to retrieve the path to the gcc installation or executable?

Edenia
  • 2,312
  • 1
  • 16
  • 33
  • Two questions there: para 1 and para 2. Best to ask one question at a time on SO since folks who can't answer all will probably not answer any. That's certainly where I am since it's quite unclear what you are asking in para 2. – Mike Kinghan Mar 19 '18 at 16:56
  • @MikeKinghan Thanks for the note, is it better now? – Edenia Mar 19 '18 at 17:02
  • Actually `set` and `echo %PATH%` will not work, because the gcc installation is usually in PATH and from there one program cannot guess which path is to gcc.exe – Edenia Mar 19 '18 at 17:06
  • Yes. Just one question after all ;) – Mike Kinghan Mar 19 '18 at 17:06

1 Answers1

1

For Linux at least, the "native GCC installation" might reasonably be interpreted as the GCC installation that is invoked through /usr/bin/gcc. But on that interpretation, there can be no doubt about its installation path.

Whenever you invoke gcc, if such a program is found at all, it is simply the first program called gcc that that is found in one of the directories listed in the value of environment variable PATH, in the environment of the invocation. True on Linux and other Unix-like OSes. True on Windows.

Imagine that gcc had an option --whereami that made it print its installation path on the standard output. The answer you will get will be the answer given by the first installation of gcc that is found in the operative PATH at the time of invocation. There might be any number of GCC installations on a system each of which will yield a different answer for gcc --whereami whenever that installation is the first to be discovered in the operative PATH.

Selection of different GCC installations via different PATH settings is commonplace on Windows, where the notion of "the native installation of GCC" has no meaning. But it is applicable on Linux too and sometimes used. The point is: no matter what command you run to find out where gcc is installed, any answer you get is in principle dependent on the operative PATH - unless you run the command with an absolute filename:

/usr/bin/gcc --whereami

which of course amounts to deciding the answer before you ask the question.

The only cross-platform method by which you can discover the directory from which gcc will be run, if at all, by a command gcc ..., is to get the operative PATH (programmatically, use getenv), parse out the the directories it contains left to right and for successive directories query the filesystem for the existence of an executable gcc within it, stopping when you find one.

And since this can only give an answer for the operative PATH, and since the value of PATH needs parsed differently on Windows and Unix-like OSes, you might just as well invoke the OS-specific utility that does the same thing.

Unix-like:

$ which gcc
/usr/bin/gcc

Windows:

C:\>where gcc
C:\mingw-w64\x86_64-7.2.0-posix-seh-rt_v5-rev0\mingw64\bin\gcc.exe

And note that in the Windows case, I needed to select my mingw-w64 terminal environment to get an answer.

To execute commands and get their output programmatically, see How can I run an external program from C and parse its output?. On Windows, call _popen instead of popen.

Mike Kinghan
  • 55,740
  • 12
  • 153
  • 182
  • Thank you, good answer. I can write a library that defines "where" or "which" depending on OS or a library that parses environment variables. Why using `_popen` though? I always used `popen` and didn't really notice any problem – Edenia Mar 19 '18 at 21:14