Since the update to mesa v23.1.1 the build without valgrind was broken.
This is a result of a change in mesa meson_options.txt which made the
valgrind support a feature in mesa:
3f10a89180 (0cc1139e3347f573ae1feee5b73dbc8a8a21fcfa_1844_1829)
So it must be explicitly turned off as it is now on by default.
Currently zink can't find libvulkan.so, so it won't work when you try to use it,
you can verify that using strace, patching RPATH fixes this.
closes#187791
The isAarch64 applies only to 64bit arm. The commit
e7a2c65ab5 missed support for 32bit arm.
This also removes kmsro as it is not used by Mesa meson.build file. The
kmsro is detected from other galium drivers. This might not be correct
and there probably should be a way to enable this in the upstream but
for now this does nothing.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
This reverts commit f4a78e4b2c.
commit 8c80bd08b7
("build-support/cc-wrapper: pass in non-existent --sysroot= to untangle
from libc") was reverted. We can drop the workaround.
Upstream doesn't enable lots of things we might actually want
by default, so just specify everything manually.
Each list is grouped into three parts: arch-independent drivers,
aarch64-only drivers and x86_64 only drivers.
If `auto` exists, the entire list of Vulkan drivers is replaced
so our additions aren't honored:
<ef168a57b9/meson.build (L258-277)>
Co-authored-by: K900 <me@0upti.me>
https://docs.mesa3d.org/relnotes/22.2.3.html
I'm merging a bit optimistically, but it's just a patch update.
At least I verified building atop current staging-next for x86_64-*
`valgrind` derivation is currently marked as broken in either:
- `stdenv.isDarwin`
- `stdenv.hostPlatform.isStatic`
Instead of adding those two checks in the `mesa` derivation, we can just
check the current `valgrind-light.meta.broken` attribute.
The required modifications in the postInstall phase are only applied on
Linux and the test currently fails on Darwin:
https://github.com/NixOS/nixpkgs/runs/5344236204
> building '/nix/store/45s58pv9j6a19wr9izx49s6i0i4qshxs-mesa-dev-does-not-depend-on-llvm.drv'...
> error: output '/nix/store/czmszfcwdx87vx2wf80lhp3h9skqqcfs-mesa-dev-does-not-depend-on-llvm' is not allowed to refer to the following paths:
> /nix/store/cwb5g57al7iizw456ah9rk49cxb47wi3-mesa-21.3.7-drivers
I've also updated the URL for the RISC-V patch in case the content of
the old URL will change (not sure if that's possible after a merge
request is merged but now that the patch is upstream it seems like a
good idea regardless; and the content has actually already changed so
the old hash wasn't correct anymore).
Note: This update likely causes some issues when running an application
that has a direct dependency on Mesa (e.g. Sway and XWayland) and was
compiled against a different Nixpkgs revision. See 7106fca0fe for more
details regarding that issue.
Note: The update to Mesa 21.0.2 was reverted (25ae1fd29f) because it
caused major issues with Sway (segfault on startup [0]).
This is still the case and might affect all packages that directly
depend on "mesa" (for libgbm or libglapi) but it only causes issues when
the package depends on a "mesa" version that differs from "mesa.drivers"
used for "/run/opengl-driver/". I've noticed this while testing Mesa
updates with the NixOS option "hardware.opengl.package" (as usual)
instead of rebuilding my whole system (which would work). Unfortunately
this can/will likely also cause issues when mixing different channels,
using Flakes/Overlays, etc.
The cause of this should be similar to [1] ("mesa" updates now cause the
same issues that "glibc" updates already do, maybe triggered by certain
Mesa changes) and some additional discussions is in [2],[3].
Note: Don't backport this to NixOS 21.05, at least not without careful
consideration.
[0]: https://github.com/NixOS/nixpkgs/pull/118753#issuecomment-818950977
[1]: https://github.com/NixOS/nixpkgs/issues/95808
[2]: https://github.com/NixOS/nixpkgs/pull/120325
[3]: https://github.com/NixOS/nixpkgs/pull/119558
OpenGL applications should not depend on the Mesa drivers, since these
are supposed to be loaded at runtime from /run/opengl-driver using the
glvnd library. Furthermore, the drivers output has a large closure
since it depends on LLVM.
The only dependency from dev to drivers came from the xatracker
pkg-config file. This commit moves this file into a new
output called driversdev.
The glvnd library contains a copy of the OpenGL headers. By compiling
against the glvnd headers we completely avoid a dependency on Mesa (and
LLVM). This reduces rebuild time. It also prevents accidents, such as
where some packages kept a reference to the mesa.drivers output and thus
had all Mesa drivers in their runtime closure.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
Latest mesa requires macOS SDK 10.13 - this applies an upstream
patch for compatibility with 10.13
Applied on darwin only to avoid linux rebuilds in staging-next - left a
note that this can be done unconditionally as it has no effect on
non-darwin platforms, if this would be considered more robust.
There's no need to keep the expressions for old patches around.
Also: Apply the musl patch unconditionally to ensure that it doesn't
break after future updates.
