Eselect (OpenGL)

Revision as of 19:28, June 28, 2014 by Drobbins (Talk | contribs)


Source Repository:Repository:Gentoo Portage Tree

Summary: A Gentoo/Funtoo utility that allows the active OpenGL implementation on a system to be switched between a variety of installed options.



Keychain 2.8.2 Released

Keychain 2.8.2, a maintenance and bug fix release, is now available.
2015-11-16 by Drobbins

Unfork Tree is Live!

The "unfork" tree is now merged into the main Funtoo Linux tree, and Funtoo Linux is now using shards for core packages, x11 (including media libraries), KDE, GNOME, python and perl.
2015-10-12 by Drobbins

OpenSSH 7 Disables DSA Keys By Default

Please be aware of this important change to avoid getting locked out of your Funtoo server.
2015-10-07 by Drobbins

Eselect (OpenGL)


We welcome improvements to this page. To edit this page, Create a Funtoo account. Then log in and then click here to edit this page. See our editing guidelines to becoming a wiki-editing pro.


Eselect (OpenGL) (also called eselect-opengl) is a module for Eselect that allows the OpenGL implementation on a Funtoo Linux or Gentoo Linux system to be switched between a variety of installed OpenGL implementations. It functions by creating an env,d file at /etc/env.d/03opengl which contains OpenGL settings. A sample env.d file for a multilib system with xorg-x11 OpenGL implementation may look like this:

/etc/env.d/03opengl - An example env.d file for eselect-opengl
# Configuration file for eselect
# This file has been automatically generated.


Eselect-opengl is implemented as a single bash-based Eselect module approximately 10K in size, installed at /usr/share/eselect/modules/opengl.eselect. One interfaces with this module via the main eselect command:

# eselect opengl help
Manage the OpenGL implementation used by your system
Usage: eselect opengl <action> <options>

Standard actions:
  help                      Display help text
  usage                     Display usage information
  version                   Display version information

Extra actions:
  list                      List the available OpenGL implementations.
  set <target>              Select the OpenGL implementation.
    <target>                  The profile to activate
    --use-old                 If an implementation is already set, use that one instead
    --prefix=<val>            Set the source prefix (default: /usr)
    --dst-prefix=<val>        Set the destination prefix (default: /usr)
    --ignore-missing          Ignore missing files when setting a new implementation
  show                      Print the current OpenGL implementation.

What is Switched

Eselect-opengl handles switching of the active:

  • Libraries (32-bit and 64-bit):
    • libGL
    • libEGL
    • libGLESv1
    • libGLESv2
  • C Headers:
    • /usr/include/GL/*
    • /usr/include/EGL/*
    • /usr/include/KHR/*

Ebuilds that provide an active OpenGL implementation install their libraries and headers in:

  • /usr/lib/opengl/(implementation-name)/lib
  • /usr/lib/opengl/(implementation-name)/include

On multilib systems, 32-bit libraries are installed to /usr/lib32/opengl/(implementation name)/lib and 64-bit libraries are installed to /usr/lib64/opengl/(implementation name)/lib.

Eselect-opengl looks in these directories for active OpenGL implementations.


Violation of Build Consistency

As documented in FL-1309, sometimes packages fail to merge when the "wrong" eselect opengl implementation is selected. This violates Portage's ability to consistently build a package from source, assuming all its dependencies are satisfied. This could be classified as a design bug -- eselect-opengl is functioning as intended, but its underlying theory of operation is not correct.

Possible Solutions

A possible solution to this problem, discussed in FL-1309, is to redesign eselect-opengl to only select the runtime OpenGL implementation, but to have all ebuilds build against the official xorg-x11 OpenGL implementation.

The rationale for this design change is that:

  1. There should be a consistent and repeatable build/linking process for all OpenGL applications.
  2. AMD and NVIDIA implementations of OpenGL are designed to be more of a "drop-in" runtime replacement for xorg-x11, rather than a standalone replacement for xorg-x11, and thus appear to exhibit more build-time bugs.