The following link in the official documentation for GCC:
http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.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:
CC
, CFLAGS
CXX
, CPPFLAGS
And linking flags:
LDFLAGS
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
?
These environment variables control the way that GCC uses localization information which allows GCC to work with different national conventions. GCC inspects the locale categories LC_CTYPE and LC_MESSAGES if it has been configured to do so. These locale categories can be set to any value supported by your installation.
By default, GCC limits the size of functions that can be inlined. This flag allows the control of this limit for functions that are explicitly marked as inline (i.e., marked with the inline keyword or defined within the class definition in c++).
Have you checked your path in the windows GUI? Search in windows (Windows+S) for "environment variables" and click "edit the system environment variables." Then click environment variables (the button). Add the path to your MinGW/bin (binaries) folder to your system PATH variable!!
This flag helps us to specify the name of the final executable produced by GCC. It places the output of the final executable in a file “file” as specified along with the flag.
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_PATH
environment 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 makefile
s) — one of the pioneering build tools. These variables were so extensively used in makefile
s 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. ;)
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 makefile
s, 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 makefile
s, 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With