Package Details: lib32-mesa-git 17.2.0_devel.92548.0d576fbfbe-1

Git Clone URL: https://aur.archlinux.org/lib32-mesa-git.git (read-only)
Package Base: lib32-mesa-git
Description: an open-source implementation of the OpenGL specification, git version
Upstream URL: http://mesa3d.sourceforge.net
Licenses: custom
Conflicts: lib32-libva-mesa-driver, lib32-mesa, lib32-mesa-libgl, lib32-mesa-vdpau, lib32-opencl-mesa, lib32-vulkan-intel, lib32-vulkan-radeon
Provides: lib32-libva-mesa-driver, lib32-mesa, lib32-mesa-libgl, lib32-mesa-vdpau, lib32-opencl-mesa, lib32-opengl-driver, lib32-vulkan-intel, lib32-vulkan-radeon
Submitter: None
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 33
Popularity: 0.095439
First Submitted: 2009-12-18 18:42
Last Updated: 2017-06-03 01:02

Required by (75)

Sources (4)

Latest Comments

Lone_Wolf commented on 2017-08-06 15:46

The commit that introduces the new symbol is :
https://cgit.freedesktop.org/mesa/mesa/commit/?id=04a40f7d2ad8fc9556c4c3a8742bbf2c948d28a0

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

Use the commit in the soruce= array, so you have :
'mesa::git://anongit.freedesktop.org/mesa/mesa#commit=04a40f7d2ad8fc9556c4c3a8742bbf2c948d28a0'

build & install.

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

Lone_Wolf commented on 2017-08-06 12:14

Confirmed.

It looks very similar to https://bugs.freedesktop.org/show_bug.cgi?id=100259 .
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

https://pastebin.com/fpSDzyf8

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 https://bugs.freedesktop.org/show_bug.cgi?id=101484

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/radeonsi_dri.so 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.

Lone_Wolf commented on 2017-05-24 10:49

100% correct, fixed.

itzexor commented on 2017-05-24 01:41

Shouldn't this provide lib32-opengl-driver instead of lib32-opengl-provider?

:: lib32-libglvnd: removing dummy-opengl-driver-git breaks dependency 'lib32-opengl-driver'

All comments