Package Details: lib32-mesa-git 21.0.0_devel.133382.735b808639b-1

Git Clone URL: (read-only, click to copy)
Package Base: lib32-mesa-git
Description: an open-source implementation of the OpenGL specification, git version
Upstream URL:
Licenses: custom
Conflicts: lib32-libva-mesa-driver, lib32-mesa, lib32-mesa-vdpau, lib32-vulkan-intel, lib32-vulkan-radeon
Provides: lib32-libva-mesa-driver, lib32-mesa, lib32-mesa-vdpau, lib32-opengl-driver, lib32-vulkan-driver, lib32-vulkan-intel, lib32-vulkan-radeon
Submitter: None
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 39
Popularity: 0.086038
First Submitted: 2009-12-18 18:42
Last Updated: 2021-01-13 12:19

Required by (89)

Sources (3)

Pinned Comments

Lone_Wolf commented on 2019-05-09 13:30

This package now uses an environment variable to determine which llvm package it will be built against. Check PKGBUILD for details.

Latest Comments

« First ‹ Previous ... 4 5 6 7 8 9 10 11 12 13 14 ... Next › Last »

Lone_Wolf commented on 2017-09-09 15:12

I just build lib32-mesa-git-17.3.0_devel.95659.e3c9425158-1-x86_64.pkg.tar.xz about 2 hours ago without problems.

Try again with makepkg --log , if it fails post the logs.

jugs commented on 2017-09-08 21:31

I'm getting the
"configure: error: Could not find llvm shared libraries..."

Same error as the guy had back in February without the warning, the PKGBUILD is up to date, and llvm-svn and lib32-llvm-svn are the latest builds.

Lone_Wolf commented on 2017-08-06 15:46

The commit that introduces the new symbol is :

There 2 later commits that uise it, and i found a third solution :

Use the commit in the soruce= array, so you have :

build & install.

revert to 'mesa::git://' .
build again, now libtool can find the symbol.

Lone_Wolf commented on 2017-08-06 12:14


It looks very similar to .
basically libtool tries to link against the *old installed* version of egl, and that one doesn't understand the new symbol.

There are 2 ways that solved this successfully in the linked bug :
- make sure the old version is not present, so libtool HAS to link against the new version we're building.
Building in a clean chroot is the easiest way to do this, see wiki for details.

- Usually the commit that introduces the new symbol is a different one then the commit(s) that use the symbol.
Figure out which commmit(s) need the new symbol , revert them and build.
Install that version , now your installed version ndoes understand the new symbol .
perform another build, now everything will build as intended.

talonz commented on 2017-08-05 20:51

having problems building lib32-mesa-git, no problems with mesa-git

jpapadopoulos commented on 2017-07-26 15:53

The black rendering issue is caused by -march=native on new Intel cpus. For more info see here

pepster commented on 2017-07-07 06:06

Also a big thanks from my side for maintaining the package.

Unfortunately I also encounter the black ogl32 problem. glxgears32 for example is 32bit.

My llvm-svn is from kerberizer.

Switching back to gcc 6.3.1-2 (and rebuilding llvn from sources because kerberizers llvm is build with gcc 7 I suppose) OR replacing /usr/lib32/xorg/modules/dri/ with an older version helps.

Lord Heavys 32bit mesa is working.

Lone_Wolf commented on 2017-07-02 20:05

I don't know of any native linux multiluib applications, but wine 32 bit games run normally ( NFS3 and Might of Magic ).

Is your llvm-svn / lib32-llvm-svn updated regularly ?

If yes,
Does mesa-git from Lord Heavy unofficial mesa-git repo have the same problems ?

p4block commented on 2017-07-02 13:54

Every time I build this (after mesa-git of course) I get completey black 32 bit opengl applications. Worst part is that they technically run, glxgears32 reports fps, steam opens (but shows blank gui) and other fun interactions.

It's been like this for a month and I'm a bit out of ideas. Anyone else encountered this?

itzexor commented on 2017-05-24 19:58

Thank you for fixing that. Thank you for maintaining these packages as well.