Building Mesa from source, a guide

I personally don't see why Canonical can't push the latest stable Mesa build to their users. It only makes the experience better as there have been massive improvements to Mesa over the past few years.

As for other distributions, it would be nice if they did the same as well but seeing as Ubuntu is the go to the choice for a lot of developers and end users it makes sense for them to do it at least.


Last edited by Johners on 13 January 2017 at 10:14 am UTC

@Johners: Ubuntu can't be bleeding edge as long as Canonical wants OEM's to consider it for preloaded systems. Software developers want a somewhat stable target as well. That's why a lot of commercial software only supports Ubuntu (LTS) releases and why basically none of it officially supports rolling release distributions. Also, gaming is still not such an important concern for Linux distros that it would significantly influence their direction.

The PPA system is a working compromise for many Ubuntu users. You don't need to restrict yourself to the official repositories.

Tank you for this. I will try it latter. But for AMD users, LLVM is also a important component when running bleeding edge Mesa, especially if you are looking for fixes of bugs. Can you please do a Wiki for how to build it too?

This is amazing! Great job!

That's more or less the approach I use. The main difference is that I use a chroot which I enter using schroot, and expose /opt from inside it for deployment directly within the chroot. Once installed, I check all 32-bit deps are met using ldd, just to be safe. eg. `find /opt/mesa-master -type f -exec ldd {} \; | grep 'not found' | sort | uniq`

I also use `make install` to install, and am not sure why that wasn't suggested on the wiki. You only need to temporarily allow write access to the target directory (/opt/mesa-master/ in the example) which can easily be reverted afterwards - and the instructions even do this anyway with the `chown root:root` command.

In my case, everything is scripted. I also have LIBGL_DRIVERS_PATH exported from a file in /etc/profile.d/ and I add my custom library paths to a file under /etc/ld.so.conf.d/ and use ldconfig so that's one less environment variable to worry about.

I also avoid setting VK_ICD_FILENAMES by adding ICD JSON files under /etc/vulkan/icd.d, which is within the default search path and doesn't seem touched by any current Debian packages.

Nice job Liam!

This should be a great help for noobs who haven't gotten to compiling yet :-)

Nice job Liam Shmerl!

This should be a great help for noobs who haven't gotten to compiling yet :-)

Fixed it for you ;)

Edit: I am currently face-planting into PHP code fixing up some new admin features for GOL, so content from me will come later tonight.


Last edited by Liam Dawe on 13 January 2017 at 3:28 pm UTC

But for AMD users, LLVM is also a important component when running bleeding edge Mesa, especially if you are looking for fixes of bugs. Can you please do a Wiki for how to build it too?

Yeah, in theory, you might want to chase the latest developments in the kernel drivers (amdgpu for instance), libdrm and llvm. But that's a whole different level of complexity. This guide assumes that you only update Mesa itself, and all the dependencies are same as the rest of the system. I didn't try building libdrm and llvm myself yet. If I'll get to it, I'll document it on the wiki :)


Last edited by Shmerl on 13 January 2017 at 3:57 pm UTC

That's more or less the approach I use. The main difference is that I use a chroot which I enter using schroot, and expose /opt from inside it for deployment directly within the chroot.

Yes, chroot or even a full blown VM is probably a cleaner approach - I mention it in the guide. It's not hard to figure out how to do it, once you know the main process.

I also use `make install` to install, and am not sure why that wasn't suggested on the wiki. You only need to temporarily allow write access to the target directory (/opt/mesa-master/ in the example) which can easily be reverted afterwards - and the instructions even do this anyway with the `chown root:root` command. In my case, everything is scripted.

You can, but I wanted only a minimal set of files. make install would deploy more stuff, and also if you mess up your prefix by mistake, it will clutter or let alone mess up some system directories. So I'd rather avoid using it in the guide. If you script it all, there is less chance of mistakes once it's tested, then it's more reasonable to use it.

I also have LIBGL_DRIVERS_PATH exported from a file in /etc/profile.d/ and I add my custom library paths to a file under /etc/ld.so.conf.d/ and use ldconfig so that's one less environment variable to worry about.

I also avoid setting VK_ICD_FILENAMES by adding ICD JSON files under /etc/vulkan/icd.d, which is within the default search path and doesn't seem touched by any current Debian packages.

I didn't want to make global overrides. The whole point was to only use custom Mesa on demand, when you want it, and let the rest of the system and applications use default Mesa. If you are confident that it works well - you can always add those global overrides in /etc/profile.d/ and /etc/vulkan/icd.d as you mentioned.


Last edited by Shmerl on 13 January 2017 at 3:56 pm UTC

I don't recommend trying to compile llvm yourself from bleeding edge git. If llvm 3.9 is available, just stick with that (if it's a version less, you won't have full GL4.5 support).

llvm 3.9 is available in Debian testing, yes. Using an unstable compiler is in general not the best idea, unless you really need it for some reason.


Last edited by Shmerl on 13 January 2017 at 7:14 pm UTC

I personally don't see why Canonical can't push the latest stable Mesa build to their users.

This discussion is moot. If you want a modern distribution with a modern update process you would go with a rolling release distro. "Stable" distros, particulary ones that aim for the server market like Ubuntu, does not make an awful lot of sense for home users, least of all gamers.

Don't get me wrong, Ubuntu is great at what it does. However, if you want the latest and greatest software, Ubuntu is not your distro. Sure, you can bridge the gap somewhat with PPAs, but that's not really a great solution to something rolling releases solves by default.

Would it be possible having some hints about "Gallium Nine" to be included within the build process? To be honest: For the moment I'm trying this out with an R600 but I don't get the DRI3-support working on my Devuan-System. :(

Would it be possible having some hints about "Gallium Nine" to be included within the build process? To be honest: For the moment I'm trying this out with an R600 but I don't get the DRI3-support working on my Devuan-System. :(

I didn't use it myself yet, so can't speak from experience. But if you'll figure out how to do it - feel free to add a section about Gallium 9 to the wiki :)

I also use `make install` to install, and am not sure why that wasn't suggested on the wiki. You only need to temporarily allow write access to the target directory (/opt/mesa-master/ in the example) which can easily be reverted afterwards - and the instructions even do this anyway with the `chown root:root` command. In my case, everything is scripted.

You can, but I wanted only a minimal set of files. make install would deploy more stuff, and also if you mess up your prefix by mistake, it will clutter or let alone mess up some system directories. So I'd rather avoid using it in the guide. If you script it all, there is less chance of mistakes once it's tested, then it's more reasonable to use it.

In my case, I chown my /opt/<mesa> directory so `make install` simply has no privileges to write anywhere else. :)

I also have LIBGL_DRIVERS_PATH exported from a file in /etc/profile.d/ and I add my custom library paths to a file under /etc/ld.so.conf.d/ and use ldconfig so that's one less environment variable to worry about.

I also avoid setting VK_ICD_FILENAMES by adding ICD JSON files under /etc/vulkan/icd.d, which is within the default search path and doesn't seem touched by any current Debian packages.

I didn't want to make global overrides. The whole point was to only use custom Mesa on demand, when you want it, and let the rest of the system and applications use default Mesa. If you are confident that it works well - you can always add those global overrides in /etc/profile.d/ and /etc/vulkan/icd.d as you mentioned.

Fair enough, that's a good idea when starting out. I actually install to /opt/mesa-<arch>-<release/date+hash> and symlink that to /opt/mesa-arch so I can always go back by just changing a symlink.

Good work in writing it all up!


Last edited by boltronics on 14 January 2017 at 2:11 am UTC

This remembers me the times when I build Mesa from source to include glide support.

Quake 2 on my Voodoo Banshee ...

And the times I compiled M.A.M.E. (again for glide support).

I'm getting old.

Luckily, turtles live many years.