Issue
The following link in the official documentation for GCC:
https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/environment-variables-affecting-gcc.html
Explains the following environment variables:
LANG
LC_CTYPE
LC_MESSAGES
LC_ALL
TMPDIR
GCC_COMPARE_DEBUG
GCC_EXEC_PREFIX
COMPILER_PATH
LIBRARY_PATH
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH
DEPENDENCIES_OUTPUT
SUNPRO_DEPENDENCIES
But I have also heard/read before about these other compiling flags:
- For compiling C code:
CC,CFLAGS - For compiling C++ code:
CXX,CPPFLAGS
And linking flags:
- For the linking stage:
LDFLAGS - After the code is compiled:
LD_LIBRARY_PATH
What is the meaning of CC, CFLAGS, CXX, and CPPFLAGS? Why aren't they included in the official list of environment variables for gcc?
Solution
To begin with, all the variables you mentioned: CC, CFLAGS, CXX, CXXFLAGS, LDFLAGS, LD_LIBRARY_PATH, are originated from Unix OS family. These variables have nothing to do with GCC in the first place, that's why you see no trace of them in the manuals.
The only meaningful variable (which has no direct connection with GCC too) among these is LD_LIBRARY_PATH. You'll probably find this variable to be defined out-of-the-box on any modern Unix-like OS. Here is the the LD.SO(8) man-page from Linux Programmer's Manual which mentions LD_LIBRARY_PATH and its purpose. Here is one more extract:
The
LD_LIBRARY_PATHenvironment variable contains a colon-separated list of directories that are searched by the dynamic linker when looking for a shared library to load.The directories are searched in the order they are mentioned in.
If not specified, the linker uses the default, which is
/lib:/usr/lib:/usr/local/lib.
As you can see LD_LIBRARY_PATH is nothing but an OS-specific environment variable for proper loading of shared libraries. Windows has similar environment variable in this regard: PATH. Windows will scan directories listed in it when searching for dynamic-link library (DLL, a counterpart of SO on Linux) too.
Concerning the rest of the variables (CC, CFLAGS, CXX, CXXFLAGS, LDFLAGS), you see them so often due to the historical reasons. Since the rise of Unix era, software projects were built using Make (scroll down and look at the examples of typical makefiles) — one of the pioneering build tools. These variables were so extensively used in makefiles that eventually they became sort of a convention (see Implicit Rules, for instance). That's why you can even see them defined out-of-the-box on, for example, Linux, and most likely pointing to GCC (as it is considered to be the native toolchain for Linux).
To conclude, the point is: don't scratch your head over CC, CFLAGS, CXX, CXXFLAGS, LDFLAGS, and friends, as they are just a blast from the past. ;)
BONUS
Using plain old Make directly to build complex software today quickly becomes tedious and error-prone. As a result, numerous sophisticated build system generators like GNU Automake or CMake have been developed. In brief, their goal is to provide (arguably) more readable, easy-to-maintain, and high-level syntax to define an arbitrarily complex build system for an arbitrary software project to be built. Typically, before actually building the project, one has to generate a native build system (which could also be represented by plain old makefiles, for example, for portability reasons, but not necessarily) out of this high-level definition using the corresponding set of tools. Finally, one has to build the project with the tool(s) corresponding to the generated (native) build system (for example, Make in case of plain old makefiles, but not necessarily).
Since you are asking these questions, I suspect that you are about to dive into native software development with C or C++. If so, I would strongly recommend you to pick a modern build system (CMake would be my personal recommendation) in the first place, play with it, and learn it well.
Answered By - Alexander Shukaev Answer Checked By - Mary Flores (WPSolving Volunteer)