Package Details: lib32-mesa-git 24.0.0_devel.179925.0e481bf4632.d41d8cd-1

Git Clone URL: https://aur.archlinux.org/lib32-mesa-git.git (read-only, click to copy)
Package Base: lib32-mesa-git
Description: an open-source implementation of the OpenGL specification, git version
Upstream URL: https://www.mesa3d.org
Licenses: custom
Conflicts: lib32-libva-mesa-driver, lib32-mesa, lib32-mesa-libgl, lib32-mesa-vdpau, lib32-vulkan-intel, lib32-vulkan-mesa-layers, lib32-vulkan-radeon
Provides: lib32-libva-mesa-driver, lib32-mesa, lib32-mesa-libgl, lib32-mesa-vdpau, lib32-opengl-driver, lib32-vulkan-driver, lib32-vulkan-intel, lib32-vulkan-mesa-layers, lib32-vulkan-radeon
Submitter: None
Maintainer: rjahanbakhshi (Lone_Wolf)
Last Packager: rjahanbakhshi
Votes: 44
Popularity: 0.59
First Submitted: 2009-12-18 18:42 (UTC)
Last Updated: 2024-03-07 21:18 (UTC)

Required by (87)

Sources (3)

Pinned Comments

Lone_Wolf commented on 2024-02-14 11:49 (UTC)

Mesa commit b52e25d3 breaks intel iris & anv build UNLESS OpenCL support is present.

Incase you don't need those drivers, a temporary workaround is to disable them.

lib32-mesa-minimal-git is also affected.

Lone_Wolf commented on 2023-11-02 16:03 (UTC) (edited on 2023-11-02 16:05 (UTC) by Lone_Wolf)

@RPINerd in https://aur.archlinux.org/packages/lib32-mesa-git#comment-941648

Users of this package are supposed to (re)build lib32-mesa-git everytime mesa-git changes to avoid such issues.

I'm certain I have stated that in the past, but it may have been lost in the older pages of comments.

Lone_Wolf commented on 2019-05-09 13:30 (UTC)

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 1 .. 11 12 13 14 15 16 17 18 19 20 21 .. 31 Next › Last »

aufkrawall commented on 2018-03-09 16:42 (UTC)

Thanks, works now (after radv got fixed).

Lone_Wolf commented on 2018-03-08 23:05 (UTC)

added valgrind as new makedepend

Lone_Wolf commented on 2018-03-08 22:26 (UTC)

confirmed, looks like mesa-git now needs valgrind installed to correctly detect libdrm version. Investigating

aufkrawall commented on 2018-03-08 11:02 (UTC)

Build fails with "configure: error: Direct rendering requires libdrm >= 2.4.75" despite 2.4.91 installed (also lib32).

Lone_Wolf commented on 2017-09-11 12:52 (UTC)

@gnanini : ./.libs/libEGL_common.a(platform_drm.o): In function `swrast_put_image2': platform_drm.c:(.text+0xa89): undefined reference to `gbm_bo_get_bpp' see my comments from 2017-08-06 . If all 3 workarounds fail, *including* building in a clean chroot, post full logs.

gnanini commented on 2017-09-10 16:53 (UTC)

I still have the same error, and the alternative method didn't worked! https://pastebin.com/YCdDqHnq

Lone_Wolf commented on 2017-09-09 15:12 (UTC)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2017-08-06 12:14 (UTC) by Lone_Wolf)

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.

« First ‹ Previous 1 .. 11 12 13 14 15 16 17 18 19 20 21 .. 31 Next › Last »