From Gentoo Wiki
< /etc‎ | portage(Redirected from Video card)
Jump to:navigation Jump to:search

/etc/portage/make.conf, previously located at /etc/make.conf, is the main configuration file used to customize the Portage environment on a global level. The /etc/portage directory contains most other Portage configuration files.

Settings in make.conf will apply to every package that is emerged. These settings control many elements of Portage functionality such as global USE flags, language (L10N) options, Portage mirrors, etc.

A very basic version gets installed while extracting the Stage file, and an example setup can be found at /usr/share/portage/config/make.conf.example.

Like many Portage configuration files, make.conf can be a directory, and its contents will get summed together as if it were a single file.

See also
The Handbook covers using make.conf, particularly in the USE flags, Portage features and Variables sections. See man make.conf for comprehensive documentation.


The final Portage configuration is not only based on make.conf. Global settings defined in this file can be refined (or redefined) on a per-package basis in the /etc/portage/package.use/ files as well as through environment variables. Default settings managed by the distribution are available as well (partially through the Portage package defaults, partially through the Gentoo profile that is in use).

Although Portage still supports the old /etc/make.conf file location, its use is discouraged in favor of /etc/portage/make.conf. When both files are available, the settings in /etc/portage/make.conf take precedence over those in /etc/make.conf.


There are many possible variables to customize in make.conf. Only the most commonly used ones are explained further within this article, with an example and a link to a more detailed article (if applicable). For more information, and the full list of variables, consult the make.conf man page by running:

user $man make.conf

Most variables are optional, can span multiple lines, but must not appear more than once.

Different configurations will require different variables to be set up. Do not treat the following examples as a definitive list, or a minimum set of requirements - set just the variables needed.


The CHOST variable is passed through the configure step of ebuilds to set the build-host of the system.

Portage profiles already set the appropriate CHOST value, and updating it requires insight and experience in build chains.
Starting with profile version 23.0 it is recommended to not to list CHOST in the make.conf file.[1]
See also
See the CHOST article for more information.


The CFLAGS and CXXFLAGS variables define the build and compile flags that will be used for all package deployments (some exceptions notwithstanding who filter out flags known to cause problems with the package). The CFLAGS variable is for C based applications, while CXXFLAGS is meant for C++ based applications. Most users will keep the content of both variables the same.

FILE /etc/portage/make.confCommonly used sane setting for CFLAGS and CXXFLAGS
CFLAGS="-march=native -O2 -pipe"
See also
For more information see the GCC optimization article, safe CFLAGS, and CFLAGS and CXXFLAGS in the Gentoo Handbook. See also the FAQ.


The CONFIG_PROTECT variable contains a space-delimited list of files and/or directories that Portage will protect from automatic modification. Proposed changes to protected configuration locations will require manual merge(s) from the system administrator (see dispatch-conf or similar merge tools).

A current list of presently protected locations can be displayed with portageq:

user $portageq envvar CONFIG_PROTECT
/etc /usr/share/config /usr/share/gnupg/qualified.txt

Using portageq is a short hand alternative to running a regular expression search on verbose, informational output from the emerge command:

user $emerge --verbose --info | grep -E '^CONFIG_PROTECT='
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt"

Files or subdirectories defined within the CONFIG_PROTECT can be excluded from protection through the CONFIG_PROTECT_MASK variable. Masking is useful when a parent directory should be protected, but a certain child directory beneath it.

The variable has a sane default setting handled by the Portage installation and the users' Gentoo profile. It can be extended through the system environment (which is often used by applications that update the variable through their /etc/env.d file) and the users' /etc/portage/make.conf setting.

FILE /etc/portage/make.confExample CONFIG_PROTECT definitions

See also the Environment variables chapter in the Gentoo Handbook.


The FEATURES variable contains a list of Portage features that the user wants enabled on the system, effectively influencing Portage's behavior. It is set by default via /usr/share/portage/config/make.globals, but can be easily updated through /etc/portage/make.conf. Since this is an incremental variable, FEATURES values can be added without directly overriding the ones implemented through the Gentoo profile.

FILE /etc/portage/make.confAdding keepwork to FEATURES in Portage

For more information, please see Portage features in the Gentoo Handbook and the FEATURES article. For a complete list of available features, see man 5 make.conf.

See also
See the FEATURES article for more information.


See also
See the GENTOO_MIRRORS article.


The MAKEOPTS variable is used to specify arguments passed to make when packages are built from source.

FILE /etc/portage/make.confRecommended setting for a dual-core processor with Hyper-Threading enabled with 8GB of RAM
See also
See the MAKEOPTS article for more information.
Read up on EMERGE_DEFAULT_OPTS as this variable influences build behavior as well.


EMERGE_DEFAULT_OPTS is a variable for Portage that defines entries to be appended to the emerge command line.

EMERGE_DEFAULT_OPTS is often used to allow for concurrent emerge operations through the --jobs N and --load-average X.Y options, which tell Portage how many package builds can be ran simultaneously and up to what system load (load average) the parallelism can be used.

For example, to run up to three build jobs simultaneously:

FILE /etc/portage/make.confEnabling 3 parallel package builds

For more information, see the EMERGE_DEFAULT_OPTS article.


See also
See the Portage niceness article.


The PORTAGE_TMPDIR variable defines the location of the temporary files for Portage. The value defaults to /var/tmp, resulting in /var/tmp/portage for the build location, /var/tmp/ccache for Portage's ccache support and so forth.

FILE /etc/portage/make.confDefault PORTAGE_TMPDIR setting

On some systems, /var/tmp/ may be mounted with the noexec option. The following error would be displayed by emerge when building packages:

user $emerge --ask package
Can not execute files in /var/tmp/portage
Likely cause is that you've mounted it with one of the
following mount options: 'noexec', 'user', 'users'
Please make sure that portage can execute files in this directory.

In this case, if removing the offending option from /etc/fstab isn't possible, PORTAGE_TMPDIR should be set to a different directory.

If enough memory is available, building packages can be accelerated by mounting PORTAGE_TMPDIR in RAM. See the article on Portage TMPDIR on tmpfs for more details.


The DISTDIR variable defines the location where Portage will store the downloaded source code archives Its value defaults to /var/cache/distfiles on new installations. Previously the default was ${PORTDIR}/distfiles which resolved to /usr/portage/distfiles by default.

Users can set the DISTDIR variable in /etc/portage/make.conf:

Beware where you place your DISTDIR! Only trusted users should be granted write access to this location.

File integrity check and unpacking is a non-atomic operation, allowing for an attack where a file is swapped in between, possibly leading to compromise the system.
FILE /etc/portage/make.confUsing a different DISTDIR location

For more information, please refer to the DISTDIR article.


PKGDIR is the location Portage keeps binary packages. By default, the location is set to /var/cache/binpkgs.

Previously, binary packages were set to ${PORTDIR}/packages, which by default resolved to /usr/portage/packages.

Run man make.conf for more information.


The USE variable allows the system wide setting or deactivation of USE flags. This variable is a space separated list and may span several lines.

FILE /etc/portage/make.confGlobal USE flags example
USE="-kde -qt5 ldap"
See also
See the article on USE flags for full explanation. See per package control of USE flags, and the /etc/portage/package.use file, about setting USE flags for an individual package.
Always consider whether it is worth setting a USE flag globally and what implications this will have on the system, or if it is preferable to just set a flag for one or several packages individually.
A USE flag may be temporarily set on the command line to check what effect it will have, before writing it to the world file: USE="[USE flag to test]" emerge --pretend --verbose --update --deep --newuse world


The ACCEPT_LICENSE variable tells Portage which software licenses are allowed. Packages who have a license that is not accepted cannot be installed on the system.

FILE /etc/portage/make.confTo accept all licenses on all packages

The preferred way to accept all licenses is to set -@EULA which allows users to check over the terms of proprietary software.

FILE /etc/portage/make.confTo accept all licenses on all packages expect proprietary
FILE /etc/portage/make.confTo accept free software only


FILE /etc/portage/make.conf
LINGUAS="de pt_BR en en_US en_GB"


The USE_EXPAND variable is a list set in profiles/base/make.defaults as of Portage[2]


See also
See the CPU_FLAGS_* article for more information.

The CPU_FLAGS_* variables inform Portage about the CPU flags (features) permitted by the CPU. This information is used to optimize package builds specifically for the targeted features. The currently supported variables are CPU_FLAGS_X86 (for amd64 and x86 architectures), CPU_FLAGS_ARM (for arm and arm64 architectures), and CPU_FLAGS_PPC (for ppc and ppc64 architectures).

The cpuid2cpuflags utility (found in the app-portage/cpuid2cpuflags package) can be used to query a complete listing of CPU flags supported by the system's processor. After emerging the package, issue:

user $cpuid2cpuflags
CPU_FLAGS_X86: aes avx f16c mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

These flags can then be added to /etc/portage/make.conf or /etc/portage/package.use/.


See the make.conf section of the Xorg/Guide article and the possible values.


See L10N in the localization guide.

FILE /etc/portage/make.conf
# Defining localization values
L10N="de pt-BR en en-US en-GB"
While common two letter language codes (like de or fr) are identical in LINGUAS and L10N, more complex entries have a different syntax because L10N uses IETF language tags (aka BCP 47). For example, pt_BR and sr@latin in LINGUAS become pt-BR and sr-Latn in L10N, respectively.


For possible values of this USE_EXPAND variable see VIDEO_CARDS.

Setting VIDEO_CARDS to appropriate value(s) will pull in the correct driver(s):

FILE /etc/portage/make.confSet VIDEO_CARDS to intel nvidia radeon vesa
VIDEO_CARDS="intel nvidia radeon vesa"

Substitute the name of the driver(s) to be used. The following table are for common combinations of machines and video cards:

Machine Discrete video card VIDEO_CARDS
Intel x86 None See Intel#Feature support
x86/ARM Nvidia nvidia
Any Nvidia except Maxwell, Pascal and Volta nouveau
Any AMD since Sea Islands amdgpu radeonsi
Any ATI and older AMD See radeon#Feature support
Any Intel intel
Raspberry Pi N/A vc4
QEMU/KVM Any virgl
WSL Any d3d12

After setting or altering VIDEO_CARDS values remember to update the system using the following command so the changes take effect:

root #emerge --ask --changed-use --deep @world

For the average user, if a graphical desktop environment is to be used this variable should be explicitly defined. For further information see the Xorg Guide make.conf section.

For more details see the AMDGPU, Intel, Nouveau, or NVIDIA articles.

See also

External resources