[bug#73071,mesa-updates,0/8] Various updates for mesa to 24.2.2

Hello Guix,

This is a series of patches to update mesa to the latest, 24.2.2, some
dependencies, and fix a vulkan issue <https://issues.guix.gnu.org/71109>.
Along the way I updated llvm-for-mesa and mesa inputs, which unifies the
changes made to build on aarch64-linux, for instance.  Hopefully this doesn't
introduce regressions.  To that end, I've pushed this series now to the
mesa-updates branch to see how building on Cuirass goes.  (A previous version
was there already, but I have updated/rebased and now finally sending this.)

Some notes:

1. The closure size of mesa has increased, something like from 374 MiB to 542
MiB, mostly due to itself (not sure why) and then also from llvm.  This is
from going from v15 to v18 and as you'll see in a patch I had to enable
building all targets.  Possibly this can be alleviated by building a smaller
clang for mesa?

2. Previous discussion was about getting NVK (which requires rust) built in
the last mesa update.  I'm not sure the current status but will check with
those that were working on it before <https://issues.guix.gnu.org/69637>.  I
believe it is no longer experimental, so we should try to include it.

Hopefully the patch changes and brief comments explain all, but please do
provide any feedback, changes, fixes, etc.  The branch has just been rebased
on master but we can rebase as needed or if there are some critical errors on
these patches I missed.

Thanks!
John

PS: I guess python-team will get this series as I added two comments (no code
changes) to python packages now needed for mesa.  One already has a huge
number of dependents anyway, but good to note I suppose.

John Kehayias (6):
  gnu: libdrm: Update to 2.4.123.
  gnu: wayland-protocols: Update to 1.37.
  gnu: Remove wayland-protocols-next.
  gnu: llvm-for-mesa: Update to llvm-18.
  gnu: llvm-for-mesa: Build all targets.
  gnu: mesa: Update to 24.2.2.

nathan (2):
  gnu: vulkan-headers: Hard-code libvulkan.so file name.
  gnu: volk: Hard-code path of vulkan-loader for dynamic loading

 gnu/packages/freedesktop.scm | 17 ++-----------
 gnu/packages/gl.scm          | 49 ++++++++++++++----------------------
 gnu/packages/kde-plasma.scm  |  2 +-
 gnu/packages/llvm.scm        | 29 ++++++++++-----------
 gnu/packages/python-xyz.scm  |  2 ++
 gnu/packages/vulkan.scm      | 41 ++++++++++++++++++++++++++----
 gnu/packages/xdisorg.scm     |  4 +--
 7 files changed, 75 insertions(+), 69 deletions(-)


base-commit: d4fbd1ab341de85c1e5c77e0f7adc5aae056be15
--
2.45.2
  

Hello, In the interest of creating a future where mesa properly works
alongside libglvnd i think there's a few options:

- simply adding "-Dglvnd=true" to mesa configure-flags and tediously adding
libglvnd to the inputs of every package that links to LibGL, as well as
patching anything problematic as mentioned in
https://issues.guix.gnu.org/49339#8

- create an abomination, the ONE MESA TO RULE THEM ALL. an example follows:

(define-public mesa/new
  (package
    (inherit mesa)
    (arguments
      (substitute-keyword-arguments (package-arguments mesa)
        ((#:configure-flags flags ''())
          #~(append #$flags
            (list "-Dglvnd=true")))
        ((#:phases phases ''())
          (with-imported-modules '((guix build union))
          #~(modify-phases #$phases
            (add-before 'validate-runpath 'unionize
              (lambda _ ;; unionize with libglvnd, fixing all problems
                (use-modules (ice-9 match)
                             (guix build union))
                (union-build (string-append #$output "/tmp")
                  '#$(list (this-package-input "libglvnd"))
                  #:create-all-directories? #t)
                (copy-recursively (string-append #$output "/tmp") #$output)
                (delete-file-recursively (string-append #$output "/tmp"))
                ;; leftovers from building with old mesa.
                ;; some packages still link to these.
                ;; remove for rebuilding after applying graft?
                (symlink (string-append #$output "/lib/libEGL.so.1")
                         (string-append #$output "/lib/libEGL.so.1.0.0"))
                (symlink (string-append #$output "/lib/libGLESv1_CM.so.1")
                         (string-append #$output
"/lib/libGLESv1_CM.so.1.1.0"))
                (symlink (string-append #$output "/lib/libGLESv2.so.2")
                         (string-append #$output "/lib/libGLESv2.so.2.0.0"))
                (symlink (string-append #$output "/lib/libGL.so.1")
                         (string-append #$output "/lib/libGL.so.1.2.0"))))
            (add-after 'install 'fix-paths
              (lambda _
                (substitute*
                  (string-append #$output
"/share/glvnd/egl_vendor.d/50_mesa.json")
                  (("libEGL_mesa")
                    (string-append #$output "/lib/libEGL_mesa")))))
            (add-after 'fix-paths 'add-external-egl
              (lambda _
                (mkdir-p (string-append #$output
"/share/egl/egl_external_platform.d")))))))))
    (native-search-paths (append (package-native-search-paths mesa)
     (list
      (search-path-specification
       (variable "__EGL_VENDOR_LIBRARY_DIRS")
       (files '("share/glvnd/egl_vendor.d")))
      (search-path-specification
       (variable "GBM_BACKENDS_PATH")
       (files '("lib")))
      (search-path-specification
       (variable "XDG_DATA_DIRS")
       (files '("share")))
      (search-path-specification
       (variable "__EGL_EXTERNAL_PLATFORM_CONFIG_DIRS")
       (files '("share/egl/egl_external_platform.d"))))))
    (inputs (modify-inputs (package-inputs mesa)
      (prepend libglvnd)))))

Using this to graft over mesa is a filthy answer to the "GL problem". no
rebuilding necessary, it seems to "just work".

Other distributions have settled on packaging mesa build for working with
libglvnd and most software seems to expect such.
Perhaps there's another solution?
  

Hello The Man :)

A note that your email went to no one; the debbugs number address is not
an alias for anyone. I happen to see your message via the issues web
interface. I would suggest adding in cc's here to whoever you intended.

On Tue, Sep 17, 2024 at 07:35 PM, The Man wrote:

> Hello, In the interest of creating a future where mesa properly works alongside libglvnd i think there's a few options:
>
> - simply adding "-Dglvnd=true" to mesa configure-flags and tediously adding libglvnd to the inputs of every package
> that links to LibGL, as well as patching anything problematic as mentioned in https://issues.guix.gnu.org/49339#8
>

This didn't seem so tidious but a countable number of packages. The
building and testing will take more time but it didn't seem too bad at
the time at least.

> - create an abomination, the ONE MESA TO RULE THEM ALL. an example follows:
>

This looks the same basically as just propagating libglvnd from mesa,
but I didn't look too carefully or try it.

In any event, we should handle this in a separate issue, get some input,
and then we can do this on a branch. My instinct is to go with what was
started in the linked issue above; add libglvnd to mesa (propagated?)
and fix failing packages assuming it isn't all 4000 or whatever (pretty
sure it is not).

> (define-public mesa/new
>   (package
>     (inherit mesa)
>     (arguments
>       (substitute-keyword-arguments (package-arguments mesa)
>         ((#:configure-flags flags ''())
>           #~(append #$flags
>             (list "-Dglvnd=true")))
>         ((#:phases phases ''())
>           (with-imported-modules '((guix build union))
>           #~(modify-phases #$phases
>             (add-before 'validate-runpath 'unionize
>               (lambda _ ;; unionize with libglvnd, fixing all problems
>                 (use-modules (ice-9 match)
>                              (guix build union))
>                 (union-build (string-append #$output "/tmp")
>                   '#$(list (this-package-input "libglvnd"))
>                   #:create-all-directories? #t)
>                 (copy-recursively (string-append #$output "/tmp") #$output)
>                 (delete-file-recursively (string-append #$output "/tmp"))
>                 ;; leftovers from building with old mesa.
>                 ;; some packages still link to these.
>                 ;; remove for rebuilding after applying graft?
>                 (symlink (string-append #$output "/lib/libEGL.so.1")
>                          (string-append #$output "/lib/libEGL.so.1.0.0"))
>                 (symlink (string-append #$output "/lib/libGLESv1_CM.so.1")
>                          (string-append #$output "/lib/libGLESv1_CM.so.1.1.0"))
>                 (symlink (string-append #$output "/lib/libGLESv2.so.2")
>                          (string-append #$output "/lib/libGLESv2.so.2.0.0"))
>                 (symlink (string-append #$output "/lib/libGL.so.1")
>                          (string-append #$output "/lib/libGL.so.1.2.0"))))
>             (add-after 'install 'fix-paths
>               (lambda _
>                 (substitute*
>                   (string-append #$output "/share/glvnd/egl_vendor.d/50_mesa.json")
>                   (("libEGL_mesa")
>                     (string-append #$output "/lib/libEGL_mesa")))))
>             (add-after 'fix-paths 'add-external-egl
>               (lambda _
>                 (mkdir-p (string-append #$output "/share/egl/egl_external_platform.d")))))))))
>     (native-search-paths (append (package-native-search-paths mesa)
>      (list
>       (search-path-specification
>        (variable "__EGL_VENDOR_LIBRARY_DIRS")
>        (files '("share/glvnd/egl_vendor.d")))
>       (search-path-specification
>        (variable "GBM_BACKENDS_PATH")
>        (files '("lib")))
>       (search-path-specification
>        (variable "XDG_DATA_DIRS")
>        (files '("share")))
>       (search-path-specification
>        (variable "__EGL_EXTERNAL_PLATFORM_CONFIG_DIRS")
>        (files '("share/egl/egl_external_platform.d"))))))
>     (inputs (modify-inputs (package-inputs mesa)
>       (prepend libglvnd)))))
>
> Using this to graft over mesa is a filthy answer to the "GL problem". no rebuilding necessary, it seems to "just work".
>
> Other distributions have settled on packaging mesa build for working with libglvnd and most software seems to expect
> such.
> Perhaps there's another solution?

It is unclear to me in Guix what this all means. I think it would mostly
be helpful on foreign distros (so libglvnd can load host's GL stuff) but
I don't know. Or perhaps for non-free related stuff (which wouldn't be
part of Guix directly in any event).

Thanks for the input!
John