Environment Variables (Using the GNU Compiler Collection (GCC))

### 3.21 Environment Variables Affecting GCC ¶

This section describes several environment variables that affect how GCC operates. Some of them work by specifying directories or prefixes to use when searching for various kinds of files. Some are used to specify other aspects of the compilation environment.

Note that you can also specify places to search using options such as `-B`, `-I` and `-L` (see Options for Directory Search). These take precedence over places specified using environment variables, which in turn take precedence over those specified by the configuration of GCC. See Controlling the Compilation Driver `gcc` in GNU Compiler Collection (GCC) Internals.

`LANG` ¶
`LC_CTYPE`
`LC_MESSAGES`
`LC_ALL`

  These environment variables control the way that GCC uses localization information that allows GCC to work with different national conventions for diagnostic and informational output. 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. A typical value is ‘`en_GB.UTF-8`’ for English in the United Kingdom encoded in UTF-8.

  If the `LC_ALL` environment variable is set, it overrides the value of `LC_CTYPE` and `LC_MESSAGES`; otherwise, `LC_CTYPE` and `LC_MESSAGES` default to the value of the `LANG` environment variable. If none of these variables are set, GCC defaults to traditional C English behavior.

  These environment variables do not affect the encodings of input files and strings in output files produced by GCC, which are controlled by the `-finput-charset` and `-fexec-charset` options, respectively. See Options Controlling the Preprocessor.

`TMPDIR` ¶

  If `TMPDIR` is set, it specifies the directory to use for temporary files. GCC uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper.

`GCC_DIAGNOSTICS_LOG` ¶

  If `GCC_DIAGNOSTICS_LOG` is set, then additional information about the diagnostics subsystem will be emitted. If it is set to an empty value, then the information will be written to stderr; otherwise, GCC will attempt to open that file and write the information there.

  The precise content and format of the information is subject to change; it is intended for use by GCC developers, rather than end-users.

`GCC_COMPARE_DEBUG` ¶

  Setting `GCC_COMPARE_DEBUG` is nearly equivalent to passing `-fcompare-debug` to the compiler driver. See the documentation of this option for more details.

`GCC_EXEC_PREFIX` ¶

  If `GCC_EXEC_PREFIX` is set, it specifies a prefix to use in the names of the subprograms executed by the compiler. No slash is added when this prefix is combined with the name of a subprogram, but you can specify a prefix that ends with a slash if you wish.

  If `GCC_EXEC_PREFIX` is not set, GCC attempts to figure out an appropriate prefix to use based on the pathname it is invoked with.

  If GCC cannot find the subprogram using the specified prefix, it tries looking in the usual places for the subprogram.

  The default value of `GCC_EXEC_PREFIX` is `prefix/lib/gcc/` where prefix is the prefix to the installed compiler. In many cases prefix is the value of `prefix` when you ran the `configure` script.

  Other prefixes specified with `-B` take precedence over this prefix.

  This prefix is also used for finding files such as `crt0.o` that are used for linking.

  In addition, the prefix is used in an unusual way in finding the directories to search for header files. For each of the standard directories whose name normally begins with ‘`/usr/local/lib/gcc`’ (more precisely, with the value of `GCC_INCLUDE_DIR`), GCC tries replacing that beginning with the specified prefix to produce an alternate directory name. Thus, with `-Bfoo/`, GCC searches `foo/bar` just before it searches the standard directory `/usr/local/lib/bar`. If a standard directory begins with the configured prefix then the value of prefix is replaced by `GCC_EXEC_PREFIX` when looking for header files.

`COMPILER_PATH` ¶

  The value of `COMPILER_PATH` is a colon-separated list of directories, much like `PATH`. GCC tries the directories thus specified when searching for subprograms, if it cannot find the subprograms using `GCC_EXEC_PREFIX`.

`LIBRARY_PATH` ¶

  The value of `LIBRARY_PATH` is a colon-separated list of directories, much like `PATH`. When configured as a native compiler, GCC tries the directories thus specified when searching for special linker files, if it cannot find them using `GCC_EXEC_PREFIX`. Linking using GCC also uses these directories when searching for ordinary libraries for the `-l` option (but directories specified with `-L` come first).

`GCC_EXTRA_DIAGNOSTIC_OUTPUT` ¶

  If `GCC_EXTRA_DIAGNOSTIC_OUTPUT` is set to one of the following values, then additional text will be emitted to stderr when fix-it hints are emitted. `-fdiagnostics-parseable-fixits` and `-fno-diagnostics-parseable-fixits` take precedence over this environment variable.

  ‘`fixits-v1`’

    Emit parseable fix-it hints, equivalent to `-fdiagnostics-parseable-fixits`. In particular, columns are expressed as a count of bytes, starting at byte 1 for the initial column.

  ‘`fixits-v2`’

    As `fixits-v1`, but columns are expressed as display columns, as per `-fdiagnostics-column-unit=display`.

`EXPERIMENTAL_SARIF_SOCKET` ¶

  If `EXPERIMENTAL_SARIF_SOCKET` is set in the environment, then the compiler will attempt to connect to a UNIX domain stream socket with that name, and send an `OnSarifResult` JSON-RPC 2.0 notification to it for each diagnostic that occurs, where the value of the notification is a SARIF `result` object.

  The compiler will fail immediately if `EXPERIMENTAL_SARIF_SOCKET` is set and it cannot connect to it.

  This feature is experimental and subject to change or removal without notice.

`COLLECT_GCC_OPTIONS` ¶

  Set by the driver and read by `collect2`, `lto-wrapper`, and the LTO linker plugin to pass the driver’s option list. If the list is too long (over 1 KiB by default), the driver writes it to a temporary file and sets this variable to ‘`@path`’ instead.

Some additional environment variables affect the behavior of the preprocessor.

`CPATH` ¶
`C_INCLUDE_PATH` ¶
`CPLUS_INCLUDE_PATH` ¶
`OBJC_INCLUDE_PATH` ¶

  Each variable’s value is a list of directories separated by a special character, much like `PATH`, in which to look for header files. The special character, `PATH_SEPARATOR`, is target-dependent and determined at GCC build time. For Microsoft Windows-based targets it is a semicolon, and for almost all other targets it is a colon.

  `CPATH` specifies a list of directories to be searched as if specified with `-I`, but after any paths given with `-I` options on the command line. This environment variable is used regardless of which language is being preprocessed.

  The remaining environment variables apply only when preprocessing the particular language indicated. Each specifies a list of directories to be searched as if specified with `-isystem`, but after any paths given with `-isystem` options on the command line.

  In all these variables, an empty element instructs the compiler to search its current working directory. Empty elements can appear at the beginning or end of a path. For instance, if the value of `CPATH` is `:/special/include`, that has the same effect as ‘`-I. -I/special/include`’.

`DEPENDENCIES_OUTPUT` ¶

  If this variable is set, its value specifies how to output dependencies for Make based on the non-system header files processed by the compiler. System header files are ignored in the dependency output.

  The value of `DEPENDENCIES_OUTPUT` can be just a file name, in which case the Make rules are written to that file, guessing the target name from the source file name. Or the value can have the form ‘`file target`’, in which case the rules are written to file file using target as the target name.

  In other words, this environment variable is equivalent to combining the options `-MM` and `-MF` (see Options Controlling the Preprocessor), with an optional `-MT` switch too.

`SUNPRO_DEPENDENCIES` ¶

  This variable is the same as `DEPENDENCIES_OUTPUT` (see above), except that system header files are not ignored, so it implies `-M` rather than `-MM`. However, the dependence on the main input file is omitted. See Options Controlling the Preprocessor.

`SOURCE_DATE_EPOCH` ¶

  If this variable is set, its value specifies a UNIX timestamp to be used in replacement of the current date and time in the `__DATE__` and `__TIME__` macros, so that the embedded timestamps become reproducible.

  The value of `SOURCE_DATE_EPOCH` must be a UNIX timestamp, defined as the number of seconds (excluding leap seconds) since 01 Jan 1970 00:00:00 represented in ASCII; identical to the output of `date +%s` on GNU/Linux and other systems that support the `%s` extension in the `date` command.

  The value should be a known timestamp such as the last modification time of the source or package and it should be set by the build process.