For those testing dxvk, it's often recommended to use latest libllvm trunk. It's a bit annoying to deal with in Debian, since [latest snapshots are outdated](https://tracker.debian.org/pkg/llvm-toolchain-snapshot), and building llvm itself from source is a tedious exercise if you just want latest Mesa with it.

Luckily, llvm developers provided these repositories with fresh nightly packages: http://apt.llvm.org

For Debian testing I used one for unstable, and it worked well. For instance, for building Mesa you can install:

llvm-7-dev
libclang-7-dev

Debian packages commonly give snapshot versions simple numbers like 7, while release versions use 6.0 and the like.

After you build Mesa and place it in your custom directory, it's also a good idea to extract .so files from the current libllvm-<ver> snapshot package and place it in the same directory. This way your bundle will be consistent until your next Mesa building.

Mesa allows building with llvm linking statically. That's a good method to avoid bundling llvm after the build explicitly.

So far I'm using --enable-llvm-shared-libs=no

I guess soon I'll need to switch to Meson anyway. Debian will need to catch up.

Building Mesa with Meson and ninja is crazy fast!

Please contribute some constructive comments. Not "it's useless to compile Mesa". I'm not interested in flaming in this thread.

I already explained reasons why I don't want to install custom Mesa from repos - it replaces the default one. Of course I could go ahead and make my own Debian packages for custom installation, that don't interfere with default Mesa, but that's an extra step. May be I'll do that at some point.

Updated build script [here](https://gist.github.com/shmerl/f4e5f76871239158cf083e37c5da56f4) to use Meson. I'll update the Wiki later a bit.

Filed llvm / clang bug to split Debian packages into regular and multilib variants. If llvm developers can do that, it will re-enable cross compiling 32-bit Mesa in 64-bit Debian, without the need for 32-bit VMs, containers or chroots.

Now that Debian finally entered deep freeze, packages like libdrm started falling behind and Mesa master doesn't build anymore as is. Is there a nice way to build it with libdrm from source? Or I need to hack around manually setting up Meson rules for custom libdrm location inside Mesa?

My goal is not to make Debian packages but to build the result. If you want to package it nicely - feel free to do it (Oibaf provides nothing of the sort I'm doing, I already explained it above). Figuring out how to build it is the hard part.

I don't need such kind of packages though, I already explained it above. Because packages replace system installation, and make it globally installed. And building will depend on system installed libdrm, which again isn't something that suits my case.

That can also depend on how destabilizing new libdrm is. I.e. if new libdrm is stable enough, it might be OK replace it globally. But it would be better to figure out how to do it in the same Mesa above is used, i.e. isolated usage.

Any news about building mesa-git on Debian? Is a chroot or vm still needed? I'm currently eyeing the switch to debian buster, but having to use older versions of mesa is holding me back. I know of ppas but I would prefer to build mesa myself

Quoting: skyrrdAny news about building mesa-git on Debian? Is a chroot or vm still needed? I'm currently eyeing the switch to debian buster, but having to use older versions of mesa is holding me back. I know of ppas but I would prefer to build mesa myself

The only reason I'm using VM is a separation from the main system, i.e. just for neatness. However I don't build 32-bit Mesa. That would likely require a VM / chroot, due to complications in setting up cross compilation. I got tired trying to make it work. Someone suggested, that if you build it with clang instead of gcc, cross compilation might work. I haven't tried it yet.

If you want newer Mesa than one in buster, you can also install Mesa packages from experimental. It has 19.0.2. See: https://tracker.debian.org/pkg/mesa
That's what I use for 32-bit anyway, due to mess of cross compiling it.

You can find my build script here if it's useful:
https://gist.github.com/shmerl/f4e5f76871239158cf083e37c5da56f4

Note, you need to have llvm repo configured, for using latest llvm snapshot.

Debian is still stuck with outdated libdrm (freeze is over, but maintainers didn't get back yet I suppose).

So I decided to figure out how to update libdrm from upstream. It's not that hard apparently.

Debian still has libdrm 2.4.97 while Mesa master now requires 2.4.99. So here is what you can do:

wget https://dri.freedesktop.org/libdrm/libdrm-2.4.99.tar.gz -O $HOME/downloads/libdrm-2.4.99.tar.gz

mkdir -p $HOME/build/libdrm
cd $HOME/build/libdrm

sudo apt-get build-dep libdrm
apt-get source libdrm

cd libdrm-2.4.97
uupdate $HOME/downloads/libdrm-2.4.99.tar.gz

cd ../libdrm-2.4.99
dpkg-buildpackage -us -uc -nc

You'll need to add some missing symbol definitions along the way to match new upstream. The build failures shows files that differ, so just add everything new to the outdated files.

To build 32-bit variant (you'll need that if you are using 32-bit Mesa), use:

apt-get build-dep -a i386 libdrm
dpkg-buildpackage -a i386 -us -uc -nc

That might require installing some cross gcc packages manually, since apparently build-dep -a i386 is not enough.

Also, when installing the result, I had to use dpkg --force-overwrite -i to work around changelog
conflicts in packages. There is probably some easy way to avoid it, but I didn't drill in enough to find it.

Just managed to build Mesa master (19.2.0 basically), as regular Debian packages using relatively easy method. It can help for those who are using Navi cards during the gap until Mesa 19.2.0 is actually released. In such case you need system Mesa packages that support Navi to get a functional desktop, and Debian doesn't provide any yet.

The method works similar to the above example with libdrm, except applied to Mesa. Use the source from:
https://gitlab.freedesktop.org/mesa/mesa/-/archive/master/mesa-master.tar.bz2

uupdate and dpkg-buildpackage do all the heavy lifting. A few tweaks are needed to debian/control, debian/rules and debian/libegl1-mesa-dev.install like to use libllvm-9-dev (instead of 8) and some other cases needed for newer Mesa, and in the end it works great!

I didn't bother building 32-bit one, since it's a lot more difficult than with libdrm on 64-bit system without having a whole 32-bit environment (VM, lxc, etc.) set up.

Building Mesa master in Debian is totally messed up now. Doesn't work with gcc-8, gcc-9, clang-9 and clang-10.

I figured out the failure. Missing coroutines llvm module. See: https://bugs.freedesktop.org/show_bug.cgi?id=111679

Temporary fix until it's fixed upstream:

diff --git a/meson.build b/meson.build
index 29d7981d13d..ce230f33875 100644
--- a/meson.build
+++ b/meson.build
@@ -1255,7 +1255,7 @@ if with_gallium_opencl
     'lto', 'option', 'objcarcopts', 'profiledata',
   ]
 endif
-if with_gallium_opencl or with_gallium_softpipe
+if with_gallium_opencl or with_gallium_softpipe or with_gallium_radeonsi or with_gallium_r600
   llvm_optional_modules += ['coroutines']
 endif

It works for me with the patch. Do you have a more detailed error message?

Ah, I know what's happening in your case I think. The script resets the source, essentially wiping out the patch. I added a couple of variables to control that. Run the script once, it will update the source but will fail (you can interrupt the building part in that run, the main step is to update the source at this point).

Then apply the patch, and run it adding these couple of flags to the ones you are usually setting:

update_sources=false reset_sources=false .... ./mesa_debian_build.sh

I'll later update the script to handle manual patches better.

Still hangs with Navi though. I tested aco-navi branch with TW3 - hangs right on startup.

I have a question, is there any way to compile Mesa by linking it to a custom libdrm folder? My system ships with an older version of the libdrm but I can compile 2.4.99 easily, all I need now is to configure Mesa to use the non-system shipped headers/libraries.

Thanks!