glfw: Use libglvnd on FreeBSD and Linux

[jwillikers]

The libglvnd package provides the necessary opengl/system dependency. The libglvnd package is a proper, non-system Conan package.

[github-actions]

🤖 Beep Boop! This pull request is making changes to 'recipes/glfw//'.

👋 @Hopobcn you might be interested. 😉

[ghost]

I detected other pull requests that are modifying glfw/all recipe:

• glfw: limit xorg library dependencies #23272

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[conan-center-bot]

Conan v1 pipeline ✔️

All green in build 2 (7bbcfece7a5a7f4195ac61bf11ed93c2314500be):

• glfw/3.3.8:
  All packages built successfully! (All logs)

• glfw/3.4:
  All packages built successfully! (All logs)

• glfw/3.3.7:
  All packages built successfully! (All logs)

• glfw/3.3.2:
  All packages built successfully! (All logs)

• glfw/3.3.4:
  All packages built successfully! (All logs)

• glfw/3.3.6:
  All packages built successfully! (All logs)

• glfw/3.3.5:
  All packages built successfully! (All logs)

• glfw/3.3.3:
  All packages built successfully! (All logs)

[jcar87]

Hi @jwillikers - thank you for opening this PR.

We'd like to understand the motivation better, as well as any potential implications. As far as I'm aware, opengl/system already handles bringing libglvnd from the system.

[jwillikers]

Hi @jwillikers - thank you for opening this PR.

We'd like to understand the motivation better, as well as any potential implications. As far as I'm aware, opengl/system already handles bringing libglvnd from the system.

@jcar87 That's exactly the problem, it's a system Conan package. Why use a system Conan package when a we have a proper Conan package that builds the library from source? My understanding is that system packages are primarily an escape-hatch when we don't have or want a proper Conan package, like in the case of X11. The system Conan packages have multiple problems, including that they don't support cross-compilation for a system like Yocto and that they need to be manually removed and rebuilt after a major distribution upgrade, i.e. Ubuntu 20.04 to Ubuntu 22.04. If we should instead use the opengl/system package, then why even have or use the libglvnd package in CCI?

I'm not sure that there are any major implications. We're just using a version of libglvnd that is built from Conan instead of the one installed on the system. We're currently using the libglvnd Conan package with my Mesa and Weston Conan packages that are in progress to run a Wayland compositor. This works well in practice, using the Conan libglvnd and mesa packages to provide graphics acceleration. The libglvnd Conan package should also work with loading system graphics drivers when used without the Mesa Conan package.

[jcar87]

My understanding is that system packages are primarily an escape-hatch when we don't have or want a proper Conan package, like in the case of X11.

This is not correct, although I can see why this can be confusing.

It is perfectly feasible to build all of X11 from source in a Conan recipe. And at "build" time, all consumer packages would build against this version perfectly fine.

The problem comes from runtime: if the version of the X11 shared libraries from Conan is different than the X server running on the system - things may not work well, especially if the Conan package is in a newer version. The applications need to talk to the server running on the host machine - the server is going to be the exact version from the system, as it is a single program running. I believe that at this stage the application (and its libraries) talk to the server via the X protocol, so we have different layers of compatibility:

• ABI compatibility between the apps/libraries we've built, and the loaded x11 libraries - here Im not too concerned, x11 is backwards compatible
• compatibility at the X level protocol at runtime The reason there is an xorg/system is to avoid the case where there may be a version mismatch
• configuration: I suspect that runtimes like x11 may load configuration files from specified locations, handled by the distros - and more often than not, the compiled code has compile-time constants for the paths of the configuration files in a specific distro. Different distros place things in different places.

I suspect the reason we don't have x11 built from source in Conan is precisely to guarantee these two compatibilities without mismatches:

• Conan Center binaries use "older" distro versions, so that the built artifacts against older x11 can still be satisfied by newer versions of the same libraries in newer distros - old school backwards abi compatibility
• Because the system libraries are always used at runtime, the clients are the server are in the same version, and the configuration is loaded where the OS expects it

these two things make graphical GUIs work when built from Conan, as far as I understand. If these assumptions are not correct, I'd be happy to start maintaining a recipe for x11 from source, and finally solve those issues :) - my concern is that if the recipes depend on "too new x11 runtime", there may be issues running them on older distros that people still use.

As for libglvnd, if I remember correctly it interfaces with both:

• x11 libraries
• system configuration: libglvnd queries the system to find the lower-level implementations
• lower-level implementations - that are installed at the system level, presumably in some location that the libglvnd implementation needs to know about

So we need to ensure that:

• libglvnd is compatible with the system x11 libraries and maybe the runtime too
• that our conan-provided libglvnd is capable of finding the vendor-specific implementations that may be installed on the system. This is critical, the search mechanism is described below:
  • https://github.com/NVIDIA/libglvnd/blob/908086d22dc307d17d0eb35c522c35fd190718cc/src/EGL/icd_enumeration.md#icd-discovery
  • https://github.com/NVIDIA/libglvnd/blob/908086d22dc307d17d0eb35c522c35fd190718cc/src/EGL/icd_enumeration.md#icd-installation
• that libglvnd is compatible and can interface with those vendor-specific implementations (e.g. nvidia, etc)

As it stands, because libglvnd has to interface with system-provided components (the x11 libraries, the system configuration folders, and the vendor-specific implementations), I am unsure of moving forward with this will actually work, and it if works, if it works across most distros.

I'm particularly concerned about the compile-time setting of the configuration directory that then the runtime searches for implementations - is it always at /usr/share/glvnd/egl_vendor.d? do some distros or systems have this somewhere else? do some distros build their libglvnd set to a different location?

That's why in some scenarios we prefer system versions rather than conan packages:

• when the libraries/apps need to interface with a system service of which there can't be multiple instances, and the version needs to be guaranteed (in particular when it comes to talking to hardware, like the graphics driver)
• when the libraries/app need have hardcoded assumptions about system configuration locations - it's safer to rely on the system libraries to find the right configurations, rather than create the potential for stuff not working at all

[jcar87]

Side notes:

The system Conan packages have multiple problems, including that they don't support cross-compilation for a system like Yocto

We probably should have a versioned, built-from-source recipe for x11 to cover for cases like this. When there is not an expectation of running anything, and x11 is already not provided by the system - it's perfectly sensible to provide it ourselves. This would also apply to x11 on macOS and Windows, if needed

and that they need to be manually removed and rebuilt after a major distribution upgrade, i.e. Ubuntu 20.04 to Ubuntu 22.04

what would need to be force-rebuilt? conan packages that were built against a previous version of the x11 headers/libraries? This should not be necessary, as far as I'm aware: x11 is probably one of the most backwards compatible libraries out there, something built against an older version should run on a system that is running a newer version - I'd be happy to look into a reproducible example where this isn't the case.

[jwillikers]

@jcar87 Fyi, you probably want to reference links to the true libglvnd and not NVIDIA's fork: https://gitlab.freedesktop.org/glvnd/libglvnd. NVIDIA's fork is the first thing that shows up in Google, which is really annoying.

First, I'll point out that I'm very confused why we only use X11 as a system package then. As I've been doing this, I've been following what we do for the Wayland and Vulkan packages. I think that Vulkan and libglvnd use a similar runtime loading mechanism, which would mean that it might have similar concerns, right? And, I thought that Wayland's client and server libraries should always be using the same version, which would also be cause for concern. Edit: This is only for the same Wayland connection that this needs to be the case, so linking multiple things to different versions of the client could potentially cause problems, as described here. I guess this is still a cause for concern as it is possible that system EGL could be linking to a different Wayland client version than the Qt Conan package which uses the Wayland Conan package, which is also built statically by default...

It's very likely that containers, containerized application deployments like snap and Flatpak, and package-mangers like Nix run into some similar concerns. For instance, the Freedesktop Flatpak packages its own version of libglvnd, seen here and mesa, seen here. My use of toolbox containers for running graphical applications also supports this, since it allows me to run apps out of completely different Linux distributions. Nix definitely works for building, installing, and running graphical applications on top of a different Linux distribution, using only its own packages. This leads me to believe it is possible to use multiple, different versions of libglvnd and mesa on a system.

Looking at the meson_options.txt, there is no specific configuration option for the path to /usr/share/glvnd/egl_vendor.d, which would require an actual patch or using a wonky data directory other than /usr/share.

On the needing to rebuild system packages, that's referring to the need to rebuild the system packages in the Conan cache to update the information retrieved from the pkg-config files. I can open a separate issue if/when I hit this again.

[Croydon]

Historical speaking, system packages have been an escape hatch, when proper Conan packages were not working, either because a lack of resources on our hands or because it might not be feasible in general. The goal was to get rid of system packages as soon as possible, if it is possible at all (similar with Conan packages that re-package downloaded binaries).

In Bincrafters we had several x11 related packages, but they never really worked at runtime
https://github.com/bincrafters/conan-x11
https://github.com/bincrafters/conan-xorgproto
https://github.com/bincrafters/conan-xorg-macros

[Croydon]

Speaking of system packages, #641 never got closed.

Edit: Just to throw in another related issue: #1207

[jwillikers]

It does appear that the libglvnd package needs a tweak to fix discovery of system ICD vendor configs, see #23500. On Linux, the search directories are subdirectories under /etc and /usr/share, which is not something that I think varies between distros that are FHS compliant. Guix and NixOS are the only ones I can think of that aren't FHS compliant. For FreeBSD, these directories are under /usr/local/etc/ and /usr/local/share. I think that covers the system search directory locations. Consumers and vendors can set the __EGL_VENDOR_LIBRARY_DIRS environment variable to accommodate the lookup directories as needed, so long as the process is not setuid.

[jcar87]

Historical speaking, system packages have been an escape hatch, when proper Conan packages were not working, either because a lack of resources on our hands or because it might not be feasible in general. The goal was to get rid of system packages as soon as possible, if it is possible at all (similar with Conan packages that re-package downloaded binaries).

Thanks for providing the historical context!!

In Bincrafters we had several x11 related packages, but they never really worked at runtime

I'm not surprised! I think it can be made to work, but it tends to be unusual to bundle a completely separate x11 stack - you eventually want apps to talk to the instance running on the host machine.

It does appear that the libglvnd package needs a tweak to fix discovery of system ICD vendor configs, see #23500.

This confirms my suspicions - merging these PRs would have actually broken things had we not identified that. I think until we are able to clarify things and ensure things work, it's best to put these on hold. I've opened an issue to track this to continue the discussion: #23649.

I don't have concerns about recipes building, and I don't have concerns about executables launching: I have concerns about the libraries in the conan package not being able to interface correctly with the X server on the machine, or the underlying hardware. The problem is that this can only truly be tested with built GUI applications that make use of OpenGL - this is not something that can be tested by our CI and I'm not seeing evidence that this has been tested more widely.

It's very likely that containers, containerized application deployments like snap and Flatpak, and package-mangers like Nix run into some similar concerns.

IIRC for Snap, x11 was one of those things you did not include in your dependencies like other isolated libraries - but my knowledge on this may be updated. With Docker, you need to specify at least the socket, with I think also may vary from system to system? That is, it may be entirely possible to have both x11 and libgl[vnd] libraries in Conan, and get it to work correctly

I think that covers the system search directory locations. Consumers and vendors can set the __EGL_VENDOR_LIBRARY_DIRS environment variable to accommodate the lookup directories as needed, so long as the process is not setuid.

We want to avoid a situation where we go from something that works without further fiddling, to something that may work or something that may require users to define that environment variable.

I'll point out that I'm very confused why we only use X11 as a system package then.
For the purposes of this conversation, I'm treating opengl/system and xorg/system as the same.

You'll find that other package managers with a problem space similar to Conan follow a similar approach.

• Binary Linux with the aim of being compatible with a broad set of Linux distros (same goal as Conan Center) treated a specific subset of libraries as "system" provided, so long as the binaries with built against an old enough version - the list is here https://peps.python.org/pep-0599/ - you;ll find not only X11 and OpenGL, but also parts of the C and C++ runtime. Even if this PEP has been superseded, it still vaguely expects certain things to be provided by the system (bearing in mind that they could otherwise be bundled/linked into the compiled modules).
• homebrew has an x11 port, but I can see from their "test" here https://github.com/Homebrew/homebrew-core/blob/3b134f092b3a266fee4b471f996f35f4e15eaef0/Formula/x/xorg-server.rb that applications are launched with the xvfb launcher - not something we want our users to have to do
• neither homebrew nor vpckg have formulas/port for libglvnd as far I can see
• Conda seems to assume OpenGL is just installed at the system level: https://github.com/conda-forge/pyopengl-feedstock/blob/main/recipe/post-link.sh#L8

Given the concerns, and the fact that I cannot find any evidence that this approach being used by package managers with similar constraints, I'd rather err on the side of caution - if what we have currently works - I would only move forward if we can prove that what is being proposed will work without friction on the widest possible set of Linux distros (including Raspberry Pi and NVIDIA Jetson).

Closing this with the intention of following the conversation and investigation at #23649