When switching from using autotools to meson, we get an error in building Mesa for macOS. This is happening in Nixpkgs master. These are the flags: ``` meson flags: --buildtype=plain --libdir=/nix/store/...-mesa-19.1.1/lib --libexecdir=/nix/store/...-mesa-19.1.1/libexec --bindir=/nix/store/...-mesa-19.1.1/bin --sbindir=/nix/store/...-mesa-19.1.1/sbin --includedir=/nix/store/...-mesa-19.1.1-dev/include --mandir=/nix/store/...-mesa-19.1.1/share/man --infodir=/nix/store/...-mesa-19.1.1/share/info --localedir=/nix/store/...-mesa-19.1.1/share/locale -Dauto_features=enabled -Dwrap_mode=nodownload --prefix=/nix/store/...-mesa-19.1.1 --sysconfdir=/etc -Db_ndebug=true -Ddisk-cache-key=/nix/store/...-mesa-19.1.1-drivers -Ddri-search-path=/run/opengl-driver/lib/dri -Dplatforms=x11 -Ddri-drivers= -Dgallium-drivers= -Dvulkan-drivers= -Ddri-drivers-path=/nix/store/...-mesa-19.1.1-drivers/lib/dri -Dvdpau-libs-path=/nix/store/...-mesa-19.1.1-drivers/lib/vdpau -Dxvmc-libs-path=/nix/store/...-mesa-19.1.1-drivers/lib -Domx-libs-path=/nix/store/...-mesa-19.1.1-drivers/lib/bellagio -Dva-libs-path=/nix/store/...-mesa-19.1.1-drivers/lib/dri -Dd3d-drivers-path=/nix/store/...-mesa-19.1.1-drivers/lib/d3d -Dgallium-vdpau=true -Dgallium-xvmc=true -Dgallium-opencl=disabled -Dshared-glapi=true -Dgles1=true -Dgles2=true -Dglx=dri -Dglvnd=true -Dllvm=true -Dshared-llvm=true -Dglx-direct=true ``` Full log is available here: https://hydra.nixos.org/build/95553754 We want to build "appledri" which provides GLX symbols around Apple's OpenGL.framework. As far as I can tell, this is fully supported with autotools, but appears broken in Meson. The error comes from this line in Mesa: https://gitlab.freedesktop.org/mesa/mesa/blame/19.1/meson.build#L367 As far as I know, there are no OpenGL drivers for macOS available from Mesa, so enabling any of those does not appear to be an option. GLX is the main thing we want to build here, so I think the above condition is incorrect. I can't find any other way to do this (macports is still on an older).
> As far as I know, there are no OpenGL drivers for macOS available from Mesa, so enabling any of those does not appear to be an option The three software rasterizers (swrast, softpipe/llvmpipe, and swr) work on macos. This configuraiton looks really strange though, because you're going to end up with gallium state trackers (vdpau and xvmc), as well as a libgles, but no drivers. Out of curiosity, what were the autotools options you were using on macos?
> The three software rasterizers (swrast, softpipe/llvmpipe, and swr) work on macos. This configuraiton looks really strange though, because you're going to end up with gallium state trackers (vdpau and xvmc), as well as a libgles, but no drivers. Ah ok! I did not realize that those worked on macOS. The configure flags do look incorrect, and might be the source of this issue. Some of this code is shared between Linux and macOS so that is where those values are coming from. Looking at it now, we should probably rely on the auto setting which will do the correct thing in most of these cases. > Out of curiosity, what were the autotools options you were using on macos? Here are the flags for autotools, which I have verified works: ``` --disable-static --disable-dependency-tracking --prefix=/nix/store/...-mesa-18.3.4 --bindir=/nix/store/...-mesa-18.3.4/bin --sbindir=/nix/store/h6q3fg99xyl2bxcxxs9jq0ha2i7m0lfz-mesa-18.3.4/sbin --includedir=/nix/store/7hxd1gvph3fy9h8ffrashfjy7msvjpbk-mesa-18.3.4-dev/include --oldincludedir=/nix/store/7hxd1gvph3fy9h8ffrashfjy7msvjpbk-mesa-18.3.4-dev/include --mandir=/nix/store/h6q3fg99xyl2bxcxxs9jq0ha2i7m0lfz-mesa-18.3.4/share/man --infodir=/nix/store/h6q3fg99xyl2bxcxxs9jq0ha2i7m0lfz-mesa-18.3.4/share/info --docdir=/nix/store/h6q3fg99xyl2bxcxxs9jq0ha2i7m0lfz-mesa-18.3.4/share/doc/mesa --libdir=/nix/store/h6q3fg99xyl2bxcxxs9jq0ha2i7m0lfz-mesa-18.3.4/lib --libexecdir=/nix/store/h6q3fg99xyl2bxcxxs9jq0ha2i7m0lfz-mesa-18.3.4/libexec --localedir=/nix/store/h6q3fg99xyl2bxcxxs9jq0ha2i7m0lfz-mesa-18.3.4/share/locale --sysconfdir=/run/opengl-driver/etc --localstatedir=/var --with-dri-driverdir=\$\(drivers\)/lib/dri --with-dri-searchpath=/run/opengl-driver/lib/dri --with-platforms=x11 --with-gallium-drivers= --with-dri-drivers= --with-vulkan-drivers= --enable-texture-float --disable-dri3 --disable-nine --disable-libglvnd --enable-dri --enable-driglx-direct --enable-gles1 --enable-gles2 --enable-glx --enable-glx-tls --disable-gallium-osmesa --enable-llvm --disable-egl --disable-xa --disable-gbm --enable-xvmc --enable-vdpau --enable-shared-glapi --enable-llvm-shared-libs --disable-omx-bellagio --disable-va --disable-opencl ``` Full log: https://hydra.nixos.org/build/95461472
Macports flags are: ``` --disable-silent-rules --with-platforms=x11 --disable-egl --disable-gbm --disable-osmesa --disable-llvm-shared-libs --with-gallium-drivers= ``` https://github.com/macports/macports-ports/blob/master/x11/mesa/Portfile
For reference, the flags we pass today on master are at https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/mesa/default.nix#L98-L132 . Generally speaking, nixpkgs errs on the side of more explicit flags rather than leaving up to configure's defaults, but yes the first priority if making it work, even if it means making a lot more of those flags platform-specific.
I've proposed a fix here for the glx bits: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1222 You really should turn off xvmc and vdpau, as even if those happen to compile (which meson should error on) they're useless. Those are state trackers that have a hard requirement on a gallium driver (for macos swrast), and are useless without one. I don't think that glvnd doesn't work on macos either, but I could be wrong
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/120.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.