Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update information about OpenGL due to libglvnd #2334

Merged
merged 4 commits into from
Oct 17, 2024
Merged

Update information about OpenGL due to libglvnd #2334

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
19751a4
Modify libglvnd information
ehfd Oct 16, 2024
b28ca05
Minor update
ehfd Oct 16, 2024
a3cf048
Add more OpenGL information
ehfd Oct 16, 2024
9e5f58b
Restore IDs
ehfd Oct 16, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 7 additions & 34 deletions docs/maintainer/knowledge_base.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -697,12 +697,7 @@ practice has been deprecated.) To add a new CDT, make a PR on the

1. When there are system specific configurations are used by the library.
Some examples include:
1. OpenGL: if we provided the OpenGL loader library `libglvnd`.
and the user's system is not using `libglvnd`, then we cannot load the vendor-specific
implementations losing out on accelerator/hardware optimized performance.
(This is only on old distributions and we may finally be able to package `libglvnd`
ourselves)
2. linux-pam: This is a library that allows pluggable authentication modules and the
1. linux-pam: This is a library that allows pluggable authentication modules and the
configuration files for these modules usually live in `/etc/pam.d`. The issue is that
the pluggable modules live in a distro specific location. For example:
`/usr/lib/x86_64-linux-gnu/security/`. The default modules are built into the
Expand All @@ -715,9 +710,9 @@ practice has been deprecated.) To add a new CDT, make a PR on the
For example: a new `glibc` package means we would have to edit the elf interpreter of
all the conda package binaries.

<a id="what-s-are-some-good-examples"></a>
<a id="what-are-some-good-examples"></a>
ehfd marked this conversation as resolved.
Show resolved Hide resolved

#### What's are some good examples?
#### What are some good examples?

1. The OpenCL loader (`ocl-icd` together with `ocl-icd-system`) provides an OpenCL
loading library. The loader will look at OpenCL implementations given in
Expand All @@ -730,41 +725,19 @@ practice has been deprecated.) To add a new CDT, make a PR on the
run OpenCL because we have a conda packaged installation, but if there is a system wide
implementation that is accelerated by specific hardware, we can use those.

In conda-forge the primary usages of CDTs is currently for packages that link against libGL.

<a id="libgl"></a>

#### libGL
### libGL

In addition to the required compilers `{{ compiler('c') }}` and/or `{{ compiler('cxx') }}`,
the following CDT packages are required for linking against libGL:
Note that packages dependent on OpenGL and/or libGL should no longer use CDTs. Instead, use the host dependency `libgl-devel` from the [libglvnd-feedstock](https://github.com/conda-forge/libglvnd-feedstock).

```yaml
requirements:
build:
- {{ cdt('mesa-libgl-devel') }} # [linux]
- {{ cdt('mesa-dri-drivers') }} # [linux]
- {{ cdt('libselinux') }} # [linux]
- {{ cdt('libxdamage') }} # [linux]
- {{ cdt('libxxf86vm') }} # [linux]
- {{ cdt('libxext') }} # [linux]
host:
- xorg-libxfixes # [linux]
```

If you need a fully functional binary in the test phase, you have to also provide the shared
libraries via `yum_requirements.txt` (see [yum_requirements.txt](#yum-deps)).

```text
mesa-libGL
mesa-dri-drivers
libselinux
libXdamage
libXxf86vm
libXext
- libgl-devel # [linux]
```

You will need to re-render the feedstock after making these changes.
Other OpenGL API variants such as `libegl-devel`, `libgles-devel`, `libglx-devel`, and `libopengl-devel` are also available, and will automatically add non-development `run_exports` dependencies.

<a id="linking-numpy"></a>

Expand Down
10 changes: 9 additions & 1 deletion docs/maintainer/maintainer_faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -131,7 +131,15 @@ Error:
ImportError: libGL.so.1: cannot open shared object file: No such file or directory
```

If you saw this error while building a package in your feedstock, create a [yum_requirements.txt](knowledge_base.md#yum-deps) file and add `mesa-libGL`. See also [CDTs: `libgl`](./knowledge_base.md#libgl).
If you saw this error while building a package in your feedstock, add the Linux host dependency `libgl-devel`, provided by the [libglvnd-feedstock](https://github.com/conda-forge/libglvnd-feedstock).

```yaml
requirements:
host:
- libgl-devel # [linux]
```

Other OpenGL API variants such as `libegl-devel`, `libgles-devel`, `libglx-devel`, and `libopengl-devel` are also available, and will automatically add non-development `run_exports` dependencies.

If you are seeing this error after installing a package locally, then you are missing an [OpenGL](https://en.wikipedia.org/wiki/OpenGL) provider in your system dependencies. This is more likely to happen in headless systems with no graphics (servers, Docker images, etc). To fix it, you must install a provider like [Mesa](https://www.mesa3d.org/) with your system package manager.

Expand Down