GLVND Version

Would it be possible to share the version of libglvnd currently bundled with the driver? I’m debugging a glvnd issue with Maya on CentOS/RHEL, and the RHEL provided libraries don’t work correctly. Overwriting them with the NVIDIA provided package manually regains working functionality.

RH is working with commit 5baa1e5cfc422eb53e66f12ffb80c93d4a693cd9 (Merge branch ‘freebsd-fixes’ v1.0.0-30-g5baa1e5 ) from the end of March 2018.

They apply the following patches:

diff -up libglvnd-1.0.0/src/generate/eglFunctionList.py.jx libglvnd-1.0.0/src/generate/eglFunctionList.py
--- libglvnd-1.0.0/src/generate/eglFunctionList.py.jx	2017-11-02 12:58:38.000000000 -0400
+++ libglvnd-1.0.0/src/generate/eglFunctionList.py	2018-03-15 12:43:19.113294070 -0400
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 
 """
 Contains a list of EGL functions to generate dispatch functions for.
diff -up libglvnd-1.0.0/src/generate/genCommon.py.jx libglvnd-1.0.0/src/generate/genCommon.py
--- libglvnd-1.0.0/src/generate/genCommon.py.jx	2017-11-02 12:58:38.000000000 -0400
+++ libglvnd-1.0.0/src/generate/genCommon.py	2018-03-15 12:37:13.260268667 -0400
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 
 # (C) Copyright 2015, NVIDIA CORPORATION.
 # All Rights Reserved.
diff -up libglvnd-1.0.0/src/generate/gen_egl_dispatch.py.jx libglvnd-1.0.0/src/generate/gen_egl_dispatch.py
--- libglvnd-1.0.0/src/generate/gen_egl_dispatch.py.jx	2017-11-02 12:58:38.000000000 -0400
+++ libglvnd-1.0.0/src/generate/gen_egl_dispatch.py	2018-03-15 12:43:00.057032312 -0400
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 
 """
 Generates dispatch functions for EGL.
diff -up libglvnd-1.0.0/src/generate/gen_gldispatch_mapi.py.jx libglvnd-1.0.0/src/generate/gen_gldispatch_mapi.py
--- libglvnd-1.0.0/src/generate/gen_gldispatch_mapi.py.jx	2017-11-02 12:58:38.000000000 -0400
+++ libglvnd-1.0.0/src/generate/gen_gldispatch_mapi.py	2018-03-15 12:37:13.283268982 -0400
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 
 # Copyright (C) 2010 LunarG Inc.
 # (C) Copyright 2015, NVIDIA CORPORATION.
diff -up libglvnd-1.0.0/src/generate/gen_libgl_glxstubs.py.jx libglvnd-1.0.0/src/generate/gen_libgl_glxstubs.py
--- libglvnd-1.0.0/src/generate/gen_libgl_glxstubs.py.jx	2017-11-02 12:58:38.000000000 -0400
+++ libglvnd-1.0.0/src/generate/gen_libgl_glxstubs.py	2018-03-15 12:37:10.684233282 -0400
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 
 # (C) Copyright 2015, NVIDIA CORPORATION.
 # All Rights Reserved.
diff -up libglvnd-1.0.0/src/generate/gen_libOpenGL_exports.py.jx libglvnd-1.0.0/src/generate/gen_libOpenGL_exports.py
--- libglvnd-1.0.0/src/generate/gen_libOpenGL_exports.py.jx	2017-11-02 12:58:38.000000000 -0400
+++ libglvnd-1.0.0/src/generate/gen_libOpenGL_exports.py	2018-03-15 12:37:13.308269324 -0400
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 
 # (C) Copyright 2015, NVIDIA CORPORATION.
 # All Rights Reserved.

===================================================

From 24606973bfabd75285fbd489264235167ba0f44c Mon Sep 17 00:00:00 2001
From: Adam Jackson <ajax@redhat.com>
Date: Thu, 14 Jun 2018 11:25:21 -0400
Subject: [PATCH] glx: Add another fallback library name

This is mostly to avoid file conflicts with external packaging.

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 src/GLX/libglxmapping.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/GLX/libglxmapping.c b/src/GLX/libglxmapping.c
index be384f8..2016a04 100644
--- a/src/GLX/libglxmapping.c
+++ b/src/GLX/libglxmapping.c
@@ -591,6 +591,10 @@ __GLXvendorInfo *__glXLookupVendorByScreen(Display *dpy, const int screen)
             vendor = __glXLookupVendorByName(FALLBACK_VENDOR_NAME);
         }
 
+        if (!vendor) {
+            vendor = __glXLookupVendorByName("system");
+        }
+
         dpyInfo->vendors[screen] = vendor;
     }
     __glvndPthreadFuncs.rwlock_unlock(&dpyInfo->vendorLock);
-- 
2.17.0

Is there an inherent incompatibility with the 410 drivers and this ‘older’ implementation?

Cheers,
Mike

If I’m reading the history correctly, it looks like 415.27 was built from commit 72bb963ff751ffd19534c2b4c5ed0ba53d007859.

I don’t know why the driver would be incompatible with an older version but if it is, it might be helpful if you could bisect libglvnd between 5baa1e5cfc and 72bb963ff7 to see where it starts working.

Alright, that’ll take some time but I’ll take a stab at building the RPM’s and replacing the source material. Would you recommend maintaining those two patches? The end goal is to diagnose whether or not this is a library or application issue. But I like to do thorough testing before I bug vendors too deeply.

Cheers,
Mike

For the first patch, if you’re just temporarily building to bisect, it’d be easiest to just temporarily make python a symlink to python3, or create a directory with a python -> python3 symlink and add it to $PATH.

I’d be very surprised if you needed the fallback library name patch. When it’s working correctly, the NVIDIA driver’s vendor name is “nvidia” so it shouldn’t get as far as the fallback names.

The following tarball has 16 builds representing all commits (minus one for just changing the version number) since the Red Hat chosen commit to current.

https://www.dropbox.com/s/g2b59qj5j7wyfik/libglvnd-builds.tar.gz?dl=0

I used the following build script to generate them (after extracting the CentOS source rpm):

#!/usr/bin/sh

mkdir -p ~/rpmbuild/{RPMS,SRPMS,BUILD,SOURCES,SPECS,tmp}

cd libglvnd

## Get libglvnd ##
URL="https://github.com/NVIDIA/libglvnd/archive/"
COMMIT="${1}"
SHORT="$(echo ${COMMIT} | sed -r 's|(.{7}).*||')"
rm libglvnd-*.tar.gz
curl -L -o libglvnd-${SHORT}.tar.gz ${URL}${COMMIT}.tar.gz

## Fix spec file ##
VERSION="${2}"
sed -i "s|%global commit0.*|%global commit0 ${COMMIT}|" libglvnd.spec
sed -i "s|Release:        ..|Release:        ${VERSION}|" libglvnd.spec

cp 0001* ~/rpmbuild/SOURCES/
cp libglvnd-python3.patch ~/rpmbuild/SOURCES/
cp libglvnd.spec ~/rpmbuild/SPECS/
cp libglvnd-${SHORT}.tar.gz ~/rpmbuild/SOURCES/

rpmbuild -ba libglvnd.spec
mkdir -p ~/libglvnd-build/${VERSION}-${SHORT}
cp -r ~/rpmbuild/RPMS ~/libglvnd-build/${VERSION}-${SHORT}/
cp -r ~/rpmbuild/SRPMS ~/libglvnd-build/${VERSION}-${SHORT}/
rm -rf ~/rpmbuild

The second sed was adjusted when switching to double digits (had to add another digit in the spec file), so originally it read only one ‘.’.

I’ll be testing these over the next few days when I have time to see if any of them do the trick.

Cheers,
Mike

Well, this problem has been solved. It wasn’t anything I was expecting, but will be on my radar from now on: systemd.

All my containers started magically working (before I even used my self-build libglvnd packages) and the only difference between them and my system were a small group of updates waiting to be installed:

systemd, systemd-libs, systemd-python, systemd-sysv, and libgudev1 which had the following in the changelog (the only two commits since RHEL 7.6’s release):

  • journald: do not store the iovec entry for process commandline on stack (#1657788)
  • journald: set a limit on the number of fields (1k) (#1657792)
  • journal-remote: set a limit on the number of fields in a message (#1657792)
  • dhcp6: make sure we have enough space for the DHCP6 option header (CVE-2018-15688)

So… systemd strikes again O.o

Cheers,
Mike