Package Details: lib32-mesa-git 22.1.0_devel.151514.a5884df949e-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-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: rjahanbakhshi
Last Packager: rjahanbakhshi
Votes: 42
Popularity: 0.098155
First Submitted: 2009-12-18 18:42 (UTC)
Last Updated: 2022-03-23 20:45 (UTC)

Required by (98)

Sources (3)

Pinned 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

rjahanbakhshi commented on 2022-03-23 20:46 (UTC)

@kogasa

I was adding the patch but noticed it's already applied upstream. So no need to do anything here.

kogasa commented on 2022-03-23 19:31 (UTC)

missing-include.patch from mesa-git is necessary and sufficient to build with llvm 15.

sir_randomuser commented on 2022-03-13 17:00 (UTC)

@Grimish

I've created a simple bash script to build mesa-git and lib32-mesa-git in a clean CHROOT, you may find it useful. Link: https://github.com/SirToffski/mesa-git-arch

It relies on using clean-chroot-manager. Very convenient - as it will automatically update the local repository with packages it builds. https://github.com/graysky2/clean-chroot-manager

Lone_Wolf commented on 2022-03-11 09:46 (UTC) (edited on 2022-03-11 09:52 (UTC) by Lone_Wolf)

clean chroot builds do require some additional setup, yes.

Below is how it goes with multilib-build from devtools package .

  • I have never found a way to pass an env var to multilib-build , set the value you want explicitly very early in the PKGBUILD (before it's used)

  • You have to pass every non-repo pacakge explicitly to the command using the -I option used by makechrootpkg .

multilib-build -- -I /path/to/package1.pkg.tar.zst -I /path/to/pacakge2.tar.zst

  • for lib32-mesa-git with MESA_WHICH_LLVM=1 you need to add 5 pacakge tarballs : llvm-libs-minimal-git , llvm-minimal-git , mesa-git , lib32-llvm-libs-minimal-git and lib32-llvm-minimal-git .

  • putting those in a script is tricky, as you have to include the correct version.

NOTE: the above also applies to mesa-git in a chroot, if you don't set MESA_WHICH_LLVM explicitly it will default to 4 and use repo llvm.

https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot has some imfo.

Grimish commented on 2022-03-10 22:09 (UTC)

Maybe i'm doing something wrong - haven't done much building in recent years so I'll jump to the chase. I build mesa-git in a clean chroot, everything works out. When I attempt to do lib32-mesa-git I run into a dependancy issue using MESA_WHICH_LLVM=1. Have not attempted any other version. I was thinking though that somehow that mesa-git has to be utilized or installed to the chroot as its mentioned among like 8 other 32-bit library dependants that pacman cannot resolve. I do enable the multilib repository in pacman as well. Not sure if thats what I'm missing. Maybe someone can help me out with that or point me in the right direction.

Thanks.

sir_randomuser commented on 2022-03-09 20:14 (UTC)

@rjahanbakhshi

Thank you!

Regarding moving lib32-libglvnd from makedepends() to depends() - not sure if that was the fix anymore. It compiled correctly once yesterday - but the more I think about it - maybe I accidentally left MESA_WHICH_LLVM undefined that time, so it used the packages from extra. Was not able to successfully compile it again.

rjahanbakhshi commented on 2022-03-09 14:25 (UTC) (edited on 2022-03-09 14:26 (UTC) by rjahanbakhshi)

@sir_randomuser

Thanks for reporting this. I'll look into it today.

sir_randomuser commented on 2022-03-08 17:14 (UTC) (edited on 2022-03-08 18:42 (UTC) by sir_randomuser)

When trying to build this package with MESA_WHICH_LLVM=2 in a clean chroot, I get the following:

How would I go about resolving this? Appreciate your help.

EDIT: this happens when dependencies are installed into chroot - before any build takes place.

EDIT2: resolved by moving lib32-libglvnd from makedepends() to depends()

error: failed to commit transaction (conflicting files)
/home/toffski/toff_build_chroot/root/usr/lib/libear/__init__.py exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libear/config.h.in exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libear/ear.c exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/__init__.py exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/analyze.py exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/arguments.py exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/clang.py exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/compilation.py exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/intercept.py exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/report.py exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/resources/scanview.css exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/resources/selectable.js exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/resources/sorttable.js exists in both 'llvm-git' and 'lib32-llvm-git'
/home/toffski/toff_build_chroot/root/usr/lib/libscanbuild/shell.py exists in both 'llvm-git' and 'lib32-llvm-git'

rjahanbakhshi commented on 2022-02-08 20:41 (UTC)

@Billli11,

Thanks for the report. PKGBUILD updated to use llvm 13.0.1

Billli11 commented on 2022-02-08 17:35 (UTC)

lib32-llvm, and lib32-llvm-libs has been updated from 13.0.0 to 13.0.1 in the official stable multilib repositories.

Please update the PKGBUILD file.

Thanks.

l_archlinux commented on 2022-01-22 15:07 (UTC) (edited on 2022-01-23 14:42 (UTC) by l_archlinux)

EDITED

i'm sorry, something was wrong on my side probably, i tried again and it worked normally.

rjahanbakhshi commented on 2021-12-15 23:25 (UTC)

@FabioLolix,
That is correct. The packages in the depends array are implicitly required to build the package, they should not be duplicated in the makedepends.
lib32-gcc-libs, lib32-libelf, mesa-git, and lib32-wayland have been removed from the makedepends array.
Thanks,

FabioLolix commented on 2021-12-15 16:56 (UTC)

packages in depends=() don't have to be in makedepends=()

rjahanbakhshi commented on 2021-12-05 11:56 (UTC)

Mesa classic drivers removed. Removed drivers are Radeon R100 and R200, old (non-gallium) Nouveau, and Intel i915 and i965.

rjahanbakhshi commented on 2021-12-01 01:03 (UTC) (edited on 2021-12-01 01:05 (UTC) by rjahanbakhshi)

@Billli11,

PKGBUILD updated to use the compiler set in CC and CXX environment variables e.g. using makepkg.conf

-m32 option will be used with the set compiler for 32-bit environment.

Billli11 commented on 2021-11-24 21:37 (UTC) (edited on 2021-11-24 21:38 (UTC) by Billli11)

Would it be possible to change line 99 and 100 to allow Clang to compile the package?

Change

export CC="gcc -m32"
export CXX="g++ -m32"

to 

export CC="${CC:-gcc} -m32"
export CXX="${CXX:-g++} -m32"

.

This should only effect if CC and CXX environment variable is set to other compiler. the package would still be compiled with GCC if the variable is not set.

Thanks.

rjahanbakhshi commented on 2021-11-13 22:41 (UTC)

PKGBUILD updated to use llvm 13.0.0

Lone_Wolf commented on 2021-10-26 11:10 (UTC)

The time has come for me to transfer ownership of this package to Reza and step down as maintainer.

Lone_Wolf

Lone_Wolf commented on 2021-08-12 17:35 (UTC)

swrast & virtio-experimental added to vulkan-drivers

Lone_Wolf commented on 2021-08-10 12:24 (UTC) (edited on 2021-08-10 12:25 (UTC) by Lone_Wolf)

adding virtio-experimental is ok, I'll try to do it this week.

lib32-mesa-git is in my view an extension of mesa-git , so there are already differences.

vulkan swrast aka lavapipe can be useful as last-resort vulkan driver and it does fulfill that role in my mesa-minimal-git & lib32-mesa-minimal-git already.

Ok, will add vulkan swrast also.

LukeShortCloud commented on 2021-08-07 16:40 (UTC)

Would it be possible to enable the virtio-experimental driver in this build? It is enabled in the mesa-git PKGBUILD. I have manually built lib32-mesa-git with it and have been testing the new Vulkan GPU passthrough support to a virtual machine with the VirtIO Venus driver with some Steam games and it works great! But, for gaming, it needs both the 64-bit and 32-bit drivers to work.

On line 115, the driver needs to be appended (this is what I have tested and have confirmed to be working):

    -D vulkan-drivers=amd,intel,virtio-experimental \

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lib32-mesa-git#n115

Looking at the mesa-git PKGBUILD, there is also the "swrast" software rendering driver. I have not tested it and perhaps for consistency across packages that should also be enabled.

   -D vulkan-drivers=amd,intel,swrast,virtio-experimental \

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mesa-git#n111

rjahanbakhshi commented on 2021-07-24 13:03 (UTC)

Removed the patch from the PKGBUILD. It should be fine now.

Thanks,

Lone_Wolf commented on 2021-07-24 12:43 (UTC) (edited on 2021-07-24 12:44 (UTC) by Lone_Wolf)

upstream solved the build failure , see https://gitlab.freedesktop.org/mesa/mesa/-/issues/4906

Until the package is updated just comment out the last 2 lines of the prepare() function .

sim590 commented on 2021-07-24 02:22 (UTC) (edited on 2021-07-24 02:30 (UTC) by sim590)

Failure while applying a patch:

==> Lancement de prepare()…
patching file src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
Hunk #1 FAILED at 351.
1 out of 1 hunk FAILED -- saving rejects to file src/gallium/auxiliary/gallivm/lp_bld_misc.cpp.rej

The patch seems to no longer be necessary as you can see from the snippet taken from the file being patched:

   TargetOptions options;
#if defined(PIPE_ARCH_X86) && LLVM_VERSION_MAJOR < 13
   options.StackAlignmentOverride = 4;
#endif

They patched it upstream.

rjahanbakhshi commented on 2021-07-12 15:12 (UTC)

@ronoverdrive,

I applied the patch used for lib32-llvm-minimal-git. Thanks to Lone_Wolf for providing the patch.

rjahanbakhshi commented on 2021-07-11 21:46 (UTC)

I haven't tested this with llvm-minimal-git recently. I'll give it a try.

ronoverdrive commented on 2021-07-11 16:27 (UTC)

Keeps failing right here.

../mesa/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp:354:12: error: ‘class llvm::TargetOptions’ has no member named ‘StackAlignmentOverride’ 354 | options.StackAlignmentOverride = 4; | ^~~~~~~~~~~~~~~~~~~~~~

I have the latest git of lib32-llvm-minimal-git installed.

rjahanbakhshi commented on 2021-06-20 16:37 (UTC)

Crocus gallium driver added to the PKGBUILD.

rjahanbakhshi commented on 2021-06-07 07:47 (UTC)

PKGBUILD updated to use llvm 12.0.0

rjahanbakhshi commented on 2021-05-10 19:12 (UTC)

The default branch is now main instead of master in the upstream. PKGBUILD updated to point to the main.

rjahanbakhshi commented on 2021-03-27 17:08 (UTC)

PKGBUILD updated to reflect the change in meson vulkan-layers options. Also the wrong commit from the last night has been reverted.

Lone_Wolf commented on 2021-01-03 15:33 (UTC)

I have switched to another package and am looking for a new maintainer.

Lone_Wolf commented on 2020-08-28 12:46 (UTC)

Using b_ndebug=true again, also cleaned up dependencies.

Thank you for the input, shoober420 and plagman.

for those using llvm  git versions : build fails, see https://gitlab.freedesktop.org/mesa/mesa/-/issues/3465

Plagman commented on 2020-08-28 01:36 (UTC)

Can ndbebug=true be re-enabled for this one too?

shoober420 commented on 2020-08-18 20:02 (UTC) (edited on 2020-08-18 20:03 (UTC) by shoober420)

@Lone_Wolf

Here are the build logs. https://pastebin.com/9vDuLrVx (build) / https://pastebin.com/TDFdgiVY (package)

Lone_Wolf commented on 2020-08-17 10:52 (UTC)

Was your build test done in a clean chroot ? If so, please post makepkg logs somewhere.

Both lib32-systemd and lib32-gcrypt were necessary at some point, but this may have changed.

I'll look into it.

shoober420 commented on 2020-08-17 04:40 (UTC)

I can confirm that “lib32-systemd” is not required for building this package. It’s also not present in the makedepends section of the official lib32-mesa package. This also means “lib32-libgcrypt” is not required for this to compile either. Please remove “lib32-systemd” and “lib32-libgcrypt”.

shoober420 commented on 2020-08-16 22:27 (UTC)

Is “lib32-systemd” really a dependency for mesa? It’s not for the 64bit version, so it kind of doesn’t make any sense.

Lone_Wolf commented on 2020-07-02 14:47 (UTC)

Both archlinux and mesa bugtrackers don't show LTO related problems with mesa afaik.

Re-enabled LTO.

Lone_Wolf commented on 2020-05-14 10:12 (UTC) (edited on 2020-05-14 10:12 (UTC) by Lone_Wolf)

Checked the bugreport, and noticed you had problems creating a trace for debugging.

None of the archlinux mesa packages (official repos, lordheavys unofficial repo, aur packages) has a debug version.

If you still want to give it a try , check https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces

HenryM commented on 2020-05-13 19:09 (UTC) (edited on 2020-05-13 19:09 (UTC) by HenryM)

I did open an issue at https://gitlab.freedesktop.org/mesa/mesa/-/issues/2935 but I just found that mesa_glthread is causing the segfault and a huge hit to performance.

if "<option name="mesa_glthread" value="true" />" is set via ~/.drirc, bad things happen to HL2 and Portal.

Lone_Wolf commented on 2020-05-09 10:16 (UTC)

That indciates your issue isn't caused by llvm variants.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/2810 is about HalfLife , but does look like it describes a different problem. Please check it and consider opening a new issue if you feel the same.

HenryM commented on 2020-05-09 07:52 (UTC)

@Lone_Wolf I tried the chaotic-aur mesa-git binary and their build of lib32-mesa-git (20.2.0_devel.123536.45c33313e6e-1) consistently crashes HL2 about 2-3 seconds after loading a level, but cs:source is completely stable

I also just built mesa-git against chaotic aur-lib32-llvm-git 11.0 myself and it behaves the same as when built against repo llvm 10.0 stable; HL2 and episodes both crash to desktop a minute or so after loading a level. cs:source continues to be stable.

Lone_Wolf commented on 2020-05-08 18:06 (UTC)

@fisch02 : yes, I'll add it.

@HenryM : please build mesa-git & lib32-mesa-git against one of the llvm trunk variants to verify whether that also has the issue (often it won't) .

Incase your system has trouble building llvm trunk, you can use the binary versions from https://wiki.archlinux.org/index.php/Unofficial_user_repositories#chaotic-aur .

PedroHLC builds many aur packages including my llvm/mesa packages regularly. The mesa-git & lib32-mesa-git in his chaotic-aur repo are build against llvm-minimal -git & lib32-llvm-minimal-git variants.

fisch02 commented on 2020-05-08 16:25 (UTC)

New steam and steam-native-runtime packages in multilib-testing depend on lib32-vulkan-driver. Can you add lib32-vulkan-driver to provides as well, similar to how its made in the regular mesa-git package ?

HenryM commented on 2020-05-08 16:25 (UTC)

I haven't touched llvm, it is the 10.0.0-1 repo package

Lone_Wolf commented on 2020-05-08 15:01 (UTC)

@HenryM Which llvm are you building against ?

If one of the llvm git versions, does the error also happen when you build against repo llvm ?

HenryM commented on 2020-05-08 13:03 (UTC)

lib32-mesa-git (20.2.0_devel.123280.f1a40a26a90-3) causes Half Life 2 and episodes to crash.

crash occurs anywhere from a few seconds after loading a map to few minutes of gameplay.

HL2 Update also crashes when trying to play any level, but the main menu does not seem to crash.

this did not happen on the previous mesa-20.1-git build, it only started after moving to 20.2-git.

running via steam-native, steam-runtime (beta and stable branches) and a desktop icon all have the same result.

However, TF2 and Counter Strike 1.6 run fine on 20.2-git, and I played over an hour of Counter Strike: Source without a problem.

when running on stable lib32-mesa 20.0.6 and also 20.1 everything appears to work fine.

I'm using an R9 390 and AMDGPU

sinatosk commented on 2020-02-13 01:13 (UTC) (edited on 2020-02-13 09:13 (UTC) by sinatosk)

Hiya, sorry for delay on response and sorry for the last post. I somehow missed that vulkan-overlay-layer was still disabled

I've enabled it again and compile is now successful.

I've deleted the previous post

Lone_Wolf commented on 2020-02-12 22:51 (UTC)

Those lines are still needed here with lib32-mesa-git-20.1.0_devel.120106.18786cc7d55-1-x86_64.pkg.tar.zst .

You are using the last PKGBUILD I uploaded ?

Lone_Wolf commented on 2020-02-11 22:55 (UTC)

Sinatosk, LordHeavy thanks for the info.

I'll disable zstd for this package until this has been solved.

lordheavy commented on 2020-02-11 17:15 (UTC)

@sinatosk

See https://bugs.archlinux.org/task/65460

sinatosk commented on 2020-02-11 16:01 (UTC) (edited on 2020-02-12 20:08 (UTC) by sinatosk)

Compiling 20.1.0_devel.120094.23037627359 fails with the following error

Linking target src/vulkan/overlay-layer/libVkLayer_MESA_overlay.so.
FAILED: src/vulkan/overlay-layer/libVkLayer_MESA_overlay.so 
g++ -m32  -o src/vulkan/overlay-layer/libVkLayer_MESA_overlay.so 'src/vulkan/overlay-layer/5cf59b8@@VkLayer_MESA_overlay@sha/overlay.cpp.o' 'src/vulkan/overlay-layer/5cf59b8@@VkLayer_MESA_overlay@sha/overlay_params.c.o' -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libVkLayer_MESA_overlay.so -march=znver1 -mtune=znver1 -O2 -pipe -fno-plt -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now src/vulkan/util/libvulkan_util.a src/util/libmesa_util.a src/util/format/libmesa_format.a src/imgui/libimgui_core.a -Wl,-Bsymbolic-functions -Wl,-z,relro /usr/lib32/libz.so -pthread -lm /usr/lib32/libxcb.so /usr/lib32/libX11-xcb.so /usr/lib32/libX11.so /usr/lib32/libxcb-dri2.so /usr/lib32/libxcb-dri3.so /usr/lib32/libxcb-present.so /usr/lib32/libxcb-sync.so /usr/lib32/libxshmfence.so /usr/lib32/libwayland-client.so /usr/lib32/libdrm.so /usr/lib32/libxcb-randr.so /usr/lib32/libXrandr.so -ldl /usr/lib/libzstd.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/../util:$ORIGIN/../../util:$ORIGIN/../../util/format:$ORIGIN/../../imgui' -Wl,-rpath-link,/home/user/pkg/aur_arch_builds/lib32-mesa-git/src/_build/src/vulkan/util -Wl,-rpath-link,/home/user/pkg/aur_arch_builds/lib32-mesa-git/src/_build/src/util -Wl,-rpath-link,/home/user/pkg/aur_arch_builds/lib32-mesa-git/src/_build/src/util/format -Wl,-rpath-link,/home/user/pkg/aur_arch_builds/lib32-mesa-git/src/_build/src/imgui
/usr/bin/ld: /usr/lib/libzstd.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
[455/1443] Generating amdgfxregs_h with a meson_exe.py custom command.
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().

I then set vulkan-overlay-layer in the PKGBUILD to false thinking it might be an issue with that

-D vulkan-overlay-layer=false \

and then the following error showed

Linking target src/gbm/libgbm.so.1.0.0.
FAILED: src/gbm/libgbm.so.1.0.0 
gcc -m32  -o src/gbm/libgbm.so.1.0.0 'src/gbm/cd6bfad@@gbm@sha/main_backend.c.o' 'src/gbm/cd6bfad@@gbm@sha/main_gbm.c.o' 'src/gbm/cd6bfad@@gbm@sha/backends_dri_gbm_dri.c.o' -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgbm.so.1 -march=znver1 -mtune=znver1 -O2 -pipe -fno-plt -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now src/loader/libloader.a src/util/libmesa_util.a src/util/format/libmesa_format.a src/util/libxmlconfig.a -Wl,--gc-sections /usr/lib32/libdrm.so /usr/lib32/libwayland-server.so -ldl -pthread /usr/lib32/libz.so -lm /usr/lib32/libexpat.so /usr/lib/libzstd.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/../loader:$ORIGIN/../util:$ORIGIN/../util/format' -Wl,-rpath-link,/home/user/pkg/aur_arch_builds/lib32-mesa-git/src/_build/src/loader -Wl,-rpath-link,/home/user/pkg/aur_arch_builds/lib32-mesa-git/src/_build/src/util -Wl,-rpath-link,/home/user/pkg/aur_arch_builds/lib32-mesa-git/src/_build/src/util/format
/usr/bin/ld: /usr/lib/libzstd.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
[746/1434] Generating sid_tables_h with a meson_exe.py custom command.
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().

so I enabled vulkan-overlay-layer again and set zstd to false thinking it might be something to do with zstd

-D zstd=false \

and now it compiles successfuly

the mesa-git 64bit package compiles fine with zstd set to auto or true or false

Lone_Wolf commented on 2020-02-02 12:35 (UTC) (edited on 2020-02-02 12:35 (UTC) by Lone_Wolf)

some possible causes

  • what happens if you unset MESA_WHICH_LLVM before makepkg ?
  • I use bash as shell, are you using something else like zsh, fish ?
  • makepkg uses pacman to install/remove deps. Do you use aliases or customized wrappers for pacman ?
  • some other package on your system has the < and > requirements, try building with extra-x86_64-build from devtools package

gardotd426 commented on 2020-02-02 07:05 (UTC)

@Lone_Wolf yeah that git clone is from today. I gave you the exact output. The entire list of commands I ran was: 


gc https://aur.archlinux.org/lib32-mesa-git.git
lib32-mesa-git
MESA_WHICH_LLVM=1 makepkg

Which followed with the error message you saw. I wasn't using an AUR helper or anything.

Lone_Wolf commented on 2020-02-02 01:20 (UTC)

Nowhere in the PKGBUILD do i use <9.1 or >= 9.0.0 .

Have you tried with a fresh git clone ?

gardotd426 commented on 2020-02-01 20:17 (UTC) (edited on 2020-02-01 20:24 (UTC) by gardotd426)

The PKGBUILD for this is broken. I have lib32-llvm-minimal-git installed as well as lib32-llvm-libs-minimal-git but no matter what MESA_WHICH_LLVM I set, it throws the same error when I try and run makepkg 


Checking runtime dependencies
Missing dependencies:
lib32-llvm-libs<9.1
Checking buildtime dependencies
Missing dependencies:
lib32-llvm>=9.0.0
lib32-llvm<9.1

You'll notice that it would be impossible to build it with llvm-minimal anyway because it's at version 11. But regardless, no matter what llvm envar I set (it's supposed to be =1) it gives that error EDIT: if you actually change the 4 to a 1 INSIDE the PKGBUILD, it no longer throws that error. But trying to use MESA_WHICH_LLVM=1 has no effect. But it works with non-lib32 mesa-git

Lone_Wolf commented on 2020-01-07 19:25 (UTC)

AwadamaFever, looks like you wanted to post that on mesa-aco-git or lib32-mesa-aco-git pages.

upstream sees no harm in having that file in /usr/bin, see https://gitlab.freedesktop.org/mesa/mesa/issues/2230 .

My solution has been to remove it in both mesa-git and lib32-mesa-git PKGBUILDS.

AwadamaFever commented on 2020-01-07 17:57 (UTC)

error: failed to commit transaction (conflicting files) /usr/bin/mesa-overlay-control.py exists in both 'mesa-aco-git' and 'lib32-mesa-aco-git' Errors occurred, no packages were upgraded.

YAOMTC commented on 2019-12-29 21:50 (UTC) (edited on 2019-12-29 23:02 (UTC) by YAOMTC)

I've installed llvm-minimal-git, lib32-llvm-minimal-git, and mesa-git. When I run makepkg on this, it tells me I'm missing "lib32-llvm=9.0.0". lib32-llvm-minimal-git provides 10, not 9. What now?

EDIT: Forgot to read the PKGBUILD, never mind. The answer is right in there, just had to change the 4 to 1.

Lone_Wolf commented on 2019-12-15 14:53 (UTC) (edited on 2019-12-15 14:53 (UTC) by Lone_Wolf)

file in /usr/bin is now removed as temp workaround, see https://gitlab.freedesktop.org/mesa/mesa/issues/2230

Ashraaf, thx for the info. It allowed me to figure out what was wrong.

I don't use vulkan often and didn't have lib32-vulkan-icd-loader installed (it was only listed as a makedepend ).

Ashraaf commented on 2019-12-14 15:30 (UTC) (edited on 2019-12-14 15:34 (UTC) by Ashraaf)

It looks like zink is running fine on my RX 580 here, using llvm-minimal-git(2ac702a). MESA_LOADER_DRIVER_OVERRIDE=zink glxgears and glxgears32 both working fine.

Output of MESA_LOADER_DRIVER_OVERRIDE=zink glxinfo -B and glxinfo32 -B show that the correct zink driver is loaded (OpenGL 2.1) and running under ACO backend.

name of display: :1
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_no_error overridden by environment.
WARNING: Experimental compiler backend enabled. Here be dragons! Incorrect rendering, GPU hangs and/or resets are likely
ATTENTION: default value of option adaptive_sync overridden by environment.
display: :1  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Collabora Ltd (0x1002)
    Device: zink (AMD RADV/ACO POLARIS10 (LLVM 10.0.0)) (0x67df)
    Version: 20.0.0
    Accelerated: yes
    Video memory: 16384MB
    Unified memory: no
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: Collabora Ltd
OpenGL renderer string: zink (AMD RADV/ACO POLARIS10 (LLVM 10.0.0))
OpenGL version string: 2.1 Mesa 20.0.0-devel (git-ce52b49348)
OpenGL shading language version string: 1.20

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.0.0-devel (git-ce52b49348)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

Lone_Wolf commented on 2019-12-14 11:48 (UTC)

This is a bit weird, as mesa /mesa-git on arch never had anything in /usr/bin .

There are some dev tools that mesa can put there, but those aren't build on archlinux. This command may need a meson flag to enable/disable building it, will look into it.

Ashraaf commented on 2019-12-14 08:21 (UTC) (edited on 2019-12-14 08:22 (UTC) by Ashraaf)

error: failed to commit transaction (conflicting files) lib32-mesa-git: /usr/bin/mesa-overlay-control.py exists in filesystem (owned by mesa-git) caused by commit 56ccea58ae7f6fd56cf4a1697d2cceb68866b552. Adding rm -rf "$pkgdir"/usr/bin/mesa-overlay-control.py solved it.

ltsdw commented on 2019-11-22 20:27 (UTC)

Yeah, you're right, my PKGBUILD in fact doesn't match with the adapted version (I was missing the export PKG_CONFIG=/usr/bin/i686-pc-linux-gnu-pkg-config). Thanks to pinpoint it to me.

Lone_Wolf commented on 2019-11-22 10:48 (UTC) (edited on 2019-11-22 10:49 (UTC) by Lone_Wolf)

I just built lib32-mesa-git without problems.

pkgconf 1.6.3-1 is the last version that used pkg-config-32, later versions use i686-pc-linux-gnu-pkg-config .

I adapted the PKGBUILD to use that on 2019-09-02 . Are you sure you're using the latest version of my PKGBUILD ?

  • your build output should have lines like :
Host machine cpu family: x86
Host machine cpu: i686
Program pkg-config found: YES (/usr/bin/pkg-config)
Found pkg-config: /usr/bin/i686-pc-linux-gnu-pkg-config (1.6.3)

ltsdw commented on 2019-11-22 06:40 (UTC) (edited on 2019-11-22 06:42 (UTC) by ltsdw)

I'm receiving a error when compiling lib32-mesa: 


meson.build:1350:0: ERROR: Pkg-config binary for machine MachineChoice.HOST not found. Giving up.
Checking the meson log I saw some relatives with pgkconf-32 not being found on directory. So the package will only compile if I make downgrade of pkgconf-1.6.3-3-x86_64 to pkgconf-1.6.3-1-x86_64

Am I loosing something?

Snoop05 commented on 2019-11-06 09:14 (UTC) (edited on 2019-11-06 09:20 (UTC) by Snoop05)

Intel UHD600, i965, iris and zink work fine, but yeah swrast spits out libGL error: image driver extension not found libGL error: failed to load driver: swrast Really strange that enabling it breaks bunch of other drivers.

Lone_Wolf commented on 2019-11-06 00:23 (UTC)

What videocard/driver do you use, snoop05 ?

With zink added I still get below errors for lib32-mesa-git (I got an AMD RX 580 )

$ glxinfo32
name of display: :0
libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib32/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib32/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths /usr/lib32/dri)
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  60
  Current serial number in output stream:  59
$

Snoop05 commented on 2019-11-05 22:48 (UTC)

I think zink can be added, it builds and runs just fine for me, with both stable and minimal-git llvm.

Lone_Wolf commented on 2019-10-30 21:31 (UTC) (edited on 2019-10-30 21:31 (UTC) by Lone_Wolf)

Snoop05,

I tried but didn't get a working package when building zink against lib32-llvm-minimal-git .

(glxinfo32 failed)

No idea when I'll have time to investigate.

Snoop05 commented on 2019-10-30 06:56 (UTC)

Can we get zink for lib32 too?

Lone_Wolf commented on 2019-09-02 13:22 (UTC) (edited on 2019-09-02 13:22 (UTC) by Lone_Wolf)

Done, thanks for the alert Demize.

demize commented on 2019-08-31 13:21 (UTC)

Please switch your PKG_CONFIG variable to point to i686-pc-linux-gnu-pkg-config instead of pkg-config-32, as the latter will be going away.

Lone_Wolf commented on 2019-06-18 21:30 (UTC)

Steinbuch, there are several commands (see below) in the package section that should prevent that. Are you building with makepkg ?

  # remove files provided by mesa-git
  rm -rf "$pkgdir"/etc
  rm -rf "$pkgdir"/usr/include
  rm -rf "$pkgdir"/usr/share/glvnd/
  rm -rf "$pkgdir"/usr/share/drirc.d/
  rm -rf "$pkgdir"/usr/share/vulkan/explicit_layer.d/

steinbuch commented on 2019-06-17 14:19 (UTC)

Files like /etc/OpenCL/vendors/mesa.icd and /usr/include/* are conflicting with mesa-git. Is this intentional?

bpierre commented on 2019-05-30 18:17 (UTC)

@Lone_Wolf: you missed a "$NINJAFLAGS" at the top of the package function:

 PKGBUILD | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git i/PKGBUILD w/PKGBUILD
index 12d6d42..164a148 100644
--- i/PKGBUILD
+++ w/PKGBUILD
@@ -138,7 +138,7 @@ build () {
 }

 package() {
-  DESTDIR="$pkgdir" ninja "$NINJAFLAGS" -C _build install
+  DESTDIR="$pkgdir" ninja $NINJAFLAGS -C _build install

   # remove files provided by mesa-git
   rm -rf "$pkgdir"/etc

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.

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

Vulkan overlay layer bug has been solved upstream, re-enabled it.

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

Lone_Wolf commented on 2019-05-04 15:38 (UTC)

Bug report for the vulkan overlay layer option https://bugs.freedesktop.org/show_bug.cgi?id=110606

Lone_Wolf commented on 2019-05-03 15:51 (UTC) (edited on 2019-05-03 15:51 (UTC) by Lone_Wolf)

vulkan-overlay-layer gives a build failure, for now that option is disabled.

Will try to register a bug report for it this weekend

Lone_Wolf commented on 2019-04-28 00:03 (UTC)

Switched to lib32-llvm-lw-git and associated packages for llvm trunk master.

Instructions to use other llvm trunk versions will be posted soon.

Lone_Wolf commented on 2019-04-15 12:12 (UTC)

Bpierre, thanks for figuring out the failure reason.

extra/lib32-llvm & llvm-svn have always had /usr/bin/llvm-config32 , so it's lib32-llvm-git that needs to be patched.

bpierre commented on 2019-04-14 21:14 (UTC)

lib32-llvm-git does not include /usr/bin/llvm-config32, but /usr/lib32/llvm-config. This work for me: https://gist.github.com/benoit-pierre/e48e125800bb385fc6378d89e1a3f9c9

PedroHLC commented on 2019-04-13 20:59 (UTC)

@Lone_Wolf Happy to hear about this update! :) Thanks again!

Lone_Wolf commented on 2019-04-12 21:03 (UTC)

I've almost finished rewriting llvm-git, will start on lib32-llvm-git soon and then adjust lib32-mesa-git when needed.

Lone_Wolf commented on 2019-04-09 14:38 (UTC) (edited on 2019-04-09 14:38 (UTC) by Lone_Wolf)

Which of the 3 options did you try :

  • my lib32-llvm-lw-git
  • lib32-llvm-git
  • lordheavy unofficial mesa-git repo

All 3 should have/provide lib32-llvm-svn & lib32-llvm-libs-svn

PedroHLC commented on 2019-04-09 10:23 (UTC)

Hi, seems like btw lib32-llvm-(svn->git) llvm is no longer a dependency of lib32-*, and when building in a clean chroot there is no llvm to use.

Thanks for all your efforts in this.

Lone_Wolf commented on 2019-04-04 11:30 (UTC)

will do that in next version this weekend

PedroHLC commented on 2019-04-03 19:51 (UTC)

Please, add glslang as dep here too.

Snoop05 commented on 2019-02-25 21:52 (UTC)

Please add 'iris' to the list of gallium drivers.

Lone_Wolf commented on 2019-01-22 12:27 (UTC)

I don't remember/can't find when I disabled it, but extra/lib32-mesa also has it disabled.

Are you aware of applications that need multilib opencl mesa support ?

YaLTeR commented on 2019-01-12 12:06 (UTC)

Why is lib32-opencl-mesa disabled actually? Is it not possible to build it?

Lone_Wolf commented on 2018-12-12 14:15 (UTC)

looks like I forgot to remove the provides/conflicts for it, will correct it in next version.

yurikoles commented on 2018-12-12 13:28 (UTC)

@Lone_Wolf

Package advertises provision of lib32-opencl-mesa, but it's disabled in meson config.

Lone_Wolf commented on 2018-11-16 19:00 (UTC)

During investigating I found adding libva and libxrandr also satifies the build. This is however due to meson not using lib32 pkg-config & llvm-config but their 64-bit counterparts. Not sure yet whether that's a meson bug or archlinux multilib build bug, but I'll start a forum thread to discuss that (extra lib32-mesa uses same method so may also suffer from this)

Added lib320libva & lib32-libxrandr to makedeps.

PedroHLC commented on 2018-11-16 12:16 (UTC)

For it to build in a clean chroot, I've needed to add 'lib32-libva' and 'lib32-libxrandr' to makedepends.

bpierre commented on 2018-11-03 15:58 (UTC)

@Lone_Wolf: this has been fixed in mesa, see https://cgit.freedesktop.org/mesa/mesa/commit/?id=1f41104b9bab50652050bf4524f2b9f371f7ca9b

Lone_Wolf commented on 2018-11-03 14:13 (UTC)

I just build mesa-git and lib32-mesa-git , neither has any files in /usr/share/locale .

I did notice a warning during build about missing locales, but that's all.

Please build mesa-git & lib32-mesa-git while adding --log to the makepkg command and post the logs somewhere public.

bpierre commented on 2018-11-01 17:24 (UTC) (edited on 2018-11-01 17:27 (UTC) by bpierre)

There are now some locale files conflicting with mesa-git too: https://gist.github.com/benoit-pierre/4e0a4f63513d81c8a7a0ca3ff57dba9c

Lone_Wolf commented on 2018-08-04 17:29 (UTC)

That appears to be caused by this commit : https://cgit.freedesktop.org/mesa/mesa/commit/?id=4334196ab325c6a19d618a392cddcc9f03adeb18

Looks like intel devs feel their tools need to be present if someone builds mesa intel drivers, even if -D tools [] is used to suppress building tools.

Not sure yet how to deal with this, but for now i'm going to remove those files during package.

ibrokemypie commented on 2018-08-04 12:27 (UTC)

Seems to conflict with mesa-git error: failed to commit transaction (conflicting files) lib32-mesa-git: /usr/bin/intel_dump_gpu exists in filesystem (owned by mesa-git) lib32-mesa-git: /usr/bin/intel_sanitize_gpu exists in filesystem (owned by mesa-git)

C0rn3j commented on 2018-05-27 08:33 (UTC)

Thanks for a quick fix, removing the packages wasn't needed, keep up being an awesome maintainer ^^

Lone_Wolf commented on 2018-05-26 13:43 (UTC)

It's been updated with those changes, C0rn3j .

Incase you're not building in a clean chroot, you may have to remove installed lib32-mesa or lib32-mesa-git with -Rdd .

C0rn3j commented on 2018-05-26 11:01 (UTC)

https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/lib32-mesa&id=b8ca1f1154b4d669c0830f89a00e74fbdff32303

https://bugs.archlinux.org/task/58725

Can't do a -Syu because this package needs a patch ^^

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.

talonz commented on 2017-08-05 20:51 (UTC)

having problems building lib32-mesa-git, no problems with mesa-git https://pastebin.com/fpSDzyf8

jpapadopoulos commented on 2017-07-26 15:53 (UTC)

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

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

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

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

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

Lone_Wolf commented on 2017-05-24 10:49 (UTC)

100% correct, fixed.

itzexor commented on 2017-05-24 01:41 (UTC)

Shouldn't this provide lib32-opengl-driver instead of lib32-opengl-provider? :: lib32-libglvnd: removing dummy-opengl-driver-git breaks dependency 'lib32-opengl-driver'

Lone_Wolf commented on 2017-05-23 17:08 (UTC)

Package is now build with glvnd support. Before building : install https://aur.archlinux.org/packages/dummy-opengl-driver-git/ (can be removed afterwards) When building outside a chroot, install lib32-libglvnd manually. If you don't, makepkg -s and -r options will fail due to conflicts.

Lone_Wolf commented on 2017-05-08 15:24 (UTC)

I put it there as a temp solution until lib32-libunwind maintainer had a chance to update. That was a month ago, the maintainer hasn't responded so I submitted an orphan request and intend to take over the package.

Gelmo commented on 2017-04-12 01:47 (UTC)

Thanks for uploading that for us, saved the day! If this happens in the future, would you be able to host it somewhere where it can be downloaded direct with wget?

Lone_Wolf commented on 2017-04-06 10:27 (UTC)

use https://app.box.com/s/f08zemx7buex8cdn6v4235rzj2qvmujs for a lib32-libunwind that does satisfy mesa-git requirements. For now you'll have to build and install it manually yourself before building lib32-mesa-git.

Berg commented on 2017-04-06 07:57 (UTC)

testing compile with lib32-libunwind from AUR and lib32-libunwind-git (AUR): /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/../../../libunwind.so when searching for -lunwind /usr/bin/ld: skipping incompatible /usr/lib/libunwind.so when searching for -lunwind /usr/bin/ld: cannot find -lunwind collect2: error: ld returned 1 exit status

Lone_Wolf commented on 2017-04-05 23:03 (UTC)

Builds fails atm because of a new dependency, lib32-libunwind. That package appears to need an update.

Lone_Wolf commented on 2017-03-17 16:14 (UTC)

same problem here, created https://bugs.freedesktop.org/show_bug.cgi?id=100259

Roberth commented on 2017-03-16 13:54 (UTC) (edited on 2017-03-16 14:08 (UTC) by Roberth)

EDIT: Removing the existing lib32-mesa-git packages before compiling fixed it. Hmmm what is wrong here? libtool: warning: relinking 'libEGL.la' libtool: install: (cd /mnt/DATA/AUR/lib32-mesa-git/src/mesa/src/egl; /bin/sh "/mnt/DATA/AUR/lib32-mesa-git/src/mesa/libtool" --silent --tag CC --mode=relink gcc -m32 -I../../include -I../../src/egl/main -I../../src/gbm/main -I../../src -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DNDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_XLOCALE_H -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DHAVE_DRI3 -DENABLE_SHADER_CACHE -DHAVE_MINCORE -DHAVE_ST_VDPAU -DHAVE_LLVM=0x0500 -DMESA_LLVM_VERSION_PATCH=0 -fvisibility=hidden -I/usr/include/libdrm -D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_X11 -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_DRM_PLATFORM -I../../src/loader -I../../src/egl/drivers/dri2 -I../../src/gbm/backends/dri -I../../src/egl/wayland/wayland-egl -I../../src/egl/wayland/wayland-drm -I../../src/egl/wayland/wayland-drm -DDEFAULT_DRIVER_DIR=\"/usr/lib32/xorg/modules/dri\" -D_EGL_BUILT_IN_DRIVER_DRI2 -march=native -mtune=native -O2 -pipe -fstack-protector-strong -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-math-errno -fno-trapping-math -no-undefined -version-number 1:0 -Wl,-Bsymbolic -Wl,--gc-sections -Wl,--no-undefined -Wl,-O1,--sort-common,--as-needed,-z,relro -o libEGL.la -rpath /usr/lib32 main/eglapi.lo main/eglarray.lo main/eglconfig.lo main/eglcontext.lo main/eglcurrent.lo main/egldisplay.lo main/egldriver.lo main/eglfallbacks.lo main/eglglobals.lo main/eglimage.lo main/egllog.lo main/eglsurface.lo main/eglsync.lo drivers/dri2/egl_dri2.lo drivers/dri2/platform_x11.lo drivers/dri2/platform_wayland.lo drivers/dri2/platform_drm.lo drivers/dri2/platform_x11_dri3.lo -ldl -lpthread -L/usr/lib32 -lX11-xcb -lX11 -lxcb -lxcb-dri2 -lxcb-xfixes ../../src/loader/libloader_dri3_helper.la -L/usr/lib32 -lwayland-client -lwayland-server -L/usr/lib32 -ldrm ../../src/egl/wayland/wayland-drm/libwayland-drm.la ../../src/gbm/libgbm.la ../../src/loader/libloader.la -ldl -L/usr/lib32 -ldrm -inst-prefix-dir /mnt/DATA/AUR/lib32-mesa-git/pkg/lib32-mesa-git) drivers/dri2/.libs/platform_drm.o: In function `get_back_bo': platform_drm.c:(.text+0x1dd): undefined reference to `gbm_bo_create_with_modifiers' collect2: error: ld returned 1 exit status libtool: error: error: relink 'libEGL.la' with the above command before installing it

Lone_Wolf commented on 2017-03-15 14:37 (UTC)

Source uri has changed, see mesa-git for details

Lone_Wolf commented on 2017-03-11 17:37 (UTC) (edited on 2017-03-11 17:38 (UTC) by Lone_Wolf)

I have looked into building aur lib32-mesa-git with libglvnd support, but the patches used in stock mesa 17.0.1-2 don't apply cleanly to git master . For now aur lib32-mesa-git is sticking to the mesa-libgl symlink method. Users that combine nvidia driver with this package may encounter problems.

Lone_Wolf commented on 2017-02-27 23:22 (UTC) (edited on 2017-02-27 23:23 (UTC) by Lone_Wolf)

migrated to scheme used in lib32-mesa-test-git, this package is now uptodate again.

Lone_Wolf commented on 2017-02-18 10:48 (UTC)

configure: WARNING: unrecognized options: --disable-vulkan-icd-full-driver-path, --with-sha1 That line in the gist indicates your PKGBUILD is an older version, download snapshot or use 'git pull' to get latest version and try again.

yurikoles commented on 2017-02-17 20:13 (UTC)

https://gist.github.com/yurikoles/76e59666f9b038bcd1a923c4677f794e configure: error: Could not find llvm shared libraries: Please make sure you have built llvm with the --enable-shared option and that your llvm libraries are installed in /usr/lib32 If you have installed your llvm libraries to a different directory you can use the --with-llvm-prefix= configure flag to specify this directory. NOTE: Mesa is attempting to use llvm shared libraries by default. If you do not want to build with llvm shared libraries and instead want to use llvm static libraries then add --disable-llvm-shared-libs to your configure invocation and rebuild. ==> ERROR: A failure occurred in build(). Aborting...

Lone_Wolf commented on 2017-02-13 12:02 (UTC)

Package fails to build atm due to the removal of ilo driver code. I have been working on a new improved git package for mesa, please switch to mesa-test-git / lib32-mesa-test-git. In approx 2 weeks (28 february) i will request lib32-mesa-test-git to be merged into this package.

Lone_Wolf commented on 2016-12-18 16:20 (UTC)

I am working on a simpler package, you can find it here : https://aur.archlinux.org/packages/lib32-mesa-test-git/ Please help to test it. aig, your comment #2 matches my own feelings. I do intend to update this package before xmas.

aig commented on 2016-12-01 22:43 (UTC)

I had some minor problems with this package recently. Maybe you can take a look at my patch for the PKGBUILD at http://pastebin.com/VdBBfuL0 1. It seems that lib32-vulkan-icd-loader now depends on lib32-vulkan-driver, which gave me some conflicts with the regular updates of my arch system 2. The .icd files in mesa-vulkan-radeon-git did get some more architecture dependend naming additions and it wasn't clear to me how they got moved to the right place in the PKGBUILD 3. The LICENSE file in mesa-vulkan-radeon-git wasn't copied to it's own subdirectory in /usr/share/licenses like it is in the mesa-vulkan-intel-git package I hope that I got things right and would be glad if the patch is useful.

kerberizer commented on 2016-11-07 19:51 (UTC) (edited on 2016-11-07 22:04 (UTC) by kerberizer)

[NOTICE] Update for the LLVM r286062 issue with Mesa is now in code review: https://patchwork.freedesktop.org/series/14932/ Edit: Updated the link.

kerberizer commented on 2016-11-07 19:51 (UTC)

[HEADS UP] LLVM r286062 breaks Mesa If you use llvm-svn with Mesa, particularly for the AMD open source driver, DO NOT upgrade LLVM to version >=r286062. Upgrading will not only break the existing driver, but will also prevent you from building Mesa altogether (in both cases there will be error messages related to missing LLVMAddFunctionAttr). If you have already upgraded to a version >=r286062, here are some possible solutions: 1. Don't restart X: everything should mostly keep running, since the older shared lib has already been loaded in memory. A fix for Mesa should emerge in the meantime, probably in a day or two at most. 2. Return to an older LLVM version: if you don't regularly clear /var/cache/pacman/pkg, you should be able to find there package versions earlier than r286062. 3. Switch to llvm/mesa from the official repositories. This may be somewhat tricky, depending on what exact packages you had installed. Try replacing as much as possible of the installed llvm-svn/mesa-git packages with their llvm/mesa counterparts. Remove the -svn/-git packages that don't have an equivalent 'provides' in the official repos. Of course, this might break some functionality for you. I'll also consider keeping older versions of the llvm-svn* packages in the binary repo as a backup. Ref: https://github.com/llvm-mirror/llvm/commit/4a6fc8bacf11d8066da72cf8481467167877ed16

kerberizer commented on 2016-07-05 22:15 (UTC)

@blinkallthetime, should be fixed soon: https://patchwork.freedesktop.org/patch/97003/

commented on 2016-07-05 17:22 (UTC)

I am getting the following error: make[4]: Entering directory '/home/barnett/sw/lib32-mesa-git/src/mesa/src/intel/vulkan' CC anv_gem.lo CC anv_entrypoints.lo CC anv_allocator.lo CC anv_batch_chain.lo CC anv_cmd_buffer.lo CC anv_descriptor_set.lo CC anv_device.lo anv_device.c:31:27: fatal error: anv_timestamp.h: No such file or directory #include "anv_timestamp.h"

Lone_Wolf commented on 2016-04-28 13:51 (UTC)

Vulkan support commented out due to build fail , see https://bugs.freedesktop.org/show_bug.cgi?id=95182

Lone_Wolf commented on 2016-04-19 15:56 (UTC)

now includes vulkan-intel driver.

kerberizer commented on 2016-02-16 18:17 (UTC)

[HEADS UP] Users of "{lib32-,}llvm-svn", "{lib32-,}mesa-git" and AMD video cards MUST recompile Mesa If __all__ of the following are true for you... * you use an AMD video card with the open source drivers, * you use "{lib32-,}mesa-git" from AUR, with version < g0bba5ca, * you use "{lib32-,}llvm-svn" from AUR, with version >= r260919, ...then you __must__ recompile the Mesa packages (or possibly upgrade again from the "mesa-git" binary repo you use). The reason is explained in this Mesa commit: https://cgit.freedesktop.org/mesa/mesa/commit/?id=0bba5ca468cdcd1f6f9bb6736c8a75e43fbe0cd5 If Mesa is not recompiled, you'll face errors of the type: libGL: dlopen /usr/lib/xorg/modules/dri/radeonsi_dri.so failed (/usr/lib/xorg/modules/dri/radeonsi_dri.so: undefined symbol: LLVMAddTargetData) Please note that with the AMD open source drivers, recompiling Mesa on every LLVM upgrade is generally a good practice, even though most of the time it will not be strictly necessary.

EndlessEden commented on 2016-02-14 02:27 (UTC)

cant get this to build... mesa-git builds fine.

Vaporeon commented on 2016-02-01 08:08 (UTC)

lib32-libxvmc seems to be missing from makedepends again.

flandoo commented on 2016-01-29 22:03 (UTC) (edited on 2016-01-29 22:35 (UTC) by flandoo)

Sorry for wasting your time, I recloned the git repo for this package and it all worked fine.. thought I already tried that :X Thanks for maintaining the package and being so responsive!

Lone_Wolf commented on 2016-01-29 21:33 (UTC) (edited on 2016-01-29 21:34 (UTC) by Lone_Wolf)

Those lines should look very different. Is your system uptodate ? do you have lib32-wayland installed ?

Lone_Wolf commented on 2016-01-28 08:42 (UTC)

How are you building this package ? lib32-xvmc is a depend of lib32-mesa-git . When building a split pacakge "makepkg -s" normally pulls in all depends & makedepends. lib32-xv is a requirement for lib32-xvmc, so they both should be pulled in.

kiffmet commented on 2016-01-27 21:23 (UTC)

please add lib32-libxv and lib32-libxvmc as depends, it does not build without them.

kerberizer commented on 2016-01-14 10:36 (UTC)

[HEADS UP] Users of `{lib32-,}llvm-svn`, `{lib32-,}mesa-git` and AMD video cards MUST recompile Mesa If ALL of the following are true for you: * you use an AMD video card with the open source drivers, * you use `{lib32-,}mesa-git` from AUR, * you use `{lib32-,}llvm-svn` from AUR, * you have upgraded the `{lib32-,}llvm-svn` packages during the last ~24 hours, whether by compiling yourself or from the `llvm-svn` binary repo, then please note that you MUST recompile the Mesa packages (or possibly upgrade again from the `mesa-git` binary repo you use). The reason is the recent branching of LLVM/Clang 3.8 and bumping the development version to 3.9, which also affects the shared library version. If Mesa is not recompiled, with the new {lib32-,}llvm-svn packages you'll face errors of the type: gbm: Last dlopen error: libLLVM-3.8svn.so: cannot open shared object file: No such file or directory (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (libLLVM-3.8svn.so: cannot open shared object file: No such file or directory) Please note that for the AMD open source drivers, recompiling Mesa on every LLVM upgrade is generally a good practice, even though most of the time it will not be strictly necessary.

Lone_Wolf commented on 2015-12-23 23:58 (UTC)

package now requires lib32-libdrm >= 2.4.66 Until [extra] lib32-libdrm gets to that version you'll have to use https://aur.archlinux.org/packages/lib32-libdrm-git/

Lone_Wolf commented on 2015-11-27 14:29 (UTC)

done, thanks

yurikoles commented on 2015-11-27 04:43 (UTC)

Please add lib32-libxvmc to makedepends.

Lone_Wolf commented on 2015-11-03 15:48 (UTC)

VirGL support has been added, you'll need kernel 4.4 or later to try it out.

kerberizer commented on 2015-10-09 11:12 (UTC)

[HEADS UP] Users of `llvm-svn`, `mesa-git` and AMD video cards MUST recompile Mesa If ALL of the following are true for you: * you use an AMD video card with open source drivers, * you use `{lib32-,}mesa-git` from AUR, * you use `{lib32-,}llvm-svn` from AUR, * you have upgraded the `{lib32-,}llvm-svn` packages during the last ~24 hours, whether by compiling yourself or from the `llvm-svn` binary repo, then please note that you MUST recompile the Mesa packages (or possibly upgrade again from the `mesa-git` binary repo you use) due to a recent change in the LLVM shared library. If Mesa is not recompiled, with the new llvm-svn packages you'll most likely face errors like this: gbm: Last dlopen error: /usr/lib/xorg/modules/dri/radeonsi_dri.so: undefined symbol: _ZN4llvm21SymbolTableListTraitsINS_11InstructionENS_10BasicBlockEE13addNodeToListEPS1_ Please note that for the AMD open source drivers recompiling Mesa on every LLVM upgrade is a good practice, even though most of the time it might not be strictly necessary.

Lone_Wolf commented on 2015-08-17 14:50 (UTC)

I have taken over lib32-mesa-git from krejzi , and will ask to merge this package to that one end of august. Please switch to lib32-mesa-git .

Krejzi commented on 2015-01-15 21:24 (UTC)

Bummer ... I did rework the entire PKGBUILD to match the one currently in community, but I only uploaded it to aur-dev, not here.

agapito commented on 2015-01-14 13:44 (UTC)

You should add: --enable-nine

Lone_Wolf commented on 2014-11-30 14:15 (UTC)

Added --enable-va & --enable-nine configure flags

smidjar2 commented on 2014-11-30 12:41 (UTC)

GalliumNine is now merged in master

Krejzi commented on 2014-10-26 09:42 (UTC)

'lib32-mesa-git/src/fakeinstall/usr/lib32/gallium-pipe’: No such file or directory As I said earlier, it's currently only used by OpenCL library and OpenCL library is not built in 32 bit package so there are no pipes at all. Master doesn't even have the GalliumNine merged yet.

Brett commented on 2014-10-24 19:02 (UTC)

I formally rescind my request regarding this package.

Brett commented on 2014-10-24 01:09 (UTC)

Gallium-pipe is used by the DirectX9 gallium statetracker with Wine when WINEARCH=win32, which is a common use case. The pipe_*.so are part of the 32-bit 3D rendering pipeline.

Krejzi commented on 2014-10-23 13:36 (UTC)

What do you need gallium-pipe for? I was told that it's only needed for OpenCL nowadays and this package doesn't build the 32 bit OCL-ICD library at all.

Brett commented on 2014-10-19 19:31 (UTC)

Hello, in the package_lib32_mesa-git() block, there's a line that reads rm -rf "${srcdir}/fakeinstall/usr/include" "${srcdir}/fakeinstall/usr/lib32/gallium-pipe" This prevents some of the 32-bit gallium-pipe rendering drivers from being installed. Please comment out the second half of that line so that the gallium-pipe/ folder isn't clobbered.

damien commented on 2014-09-11 03:06 (UTC)

Hi, could we change line 72 to use "mkdir -p" so that the build doesn't fail if src/fakeinstall already exists? This is also what the mesa-git package does.

agapito commented on 2014-08-28 17:26 (UTC)

Thanks avengerf12. I need it.

avengerf12 commented on 2014-08-21 14:21 (UTC)

Currently this package doesn't work, so here is a fixed PKGBUILD if someone needs it. http://pastebin.com/j8KTGrUk

agapito commented on 2014-08-13 22:25 (UTC)

Something is wrong i guess checking for RADEON... yes checking for RADEON... yes checking for NOUVEAU... yes checking for mincore... yes configure: error: gbm_gallium is only used by egl_gallium I can't build it.

Krejzi commented on 2014-08-01 09:24 (UTC)

Both are part of base-devel group, and AUR packages don't need to depend on such packages.

Weegee commented on 2014-08-01 09:17 (UTC)

Doesn't build without bison and flex installed for me, are they missing from makedepends?

Lone_Wolf commented on 2014-03-27 11:41 (UTC)

- switched from classic osmesa to gallium osmesa - enabled gallium tests

Lone_Wolf commented on 2014-03-15 13:21 (UTC)

changed some dependencies

Lone_Wolf commented on 2014-03-13 11:39 (UTC)

Adjusted to reflect changes in lib32-mesa-10.1.0-3, wayland support now included.

Lone_Wolf commented on 2014-02-02 18:50 (UTC)

corrected dependencies, now builds against lib32-llvm-svn . version numbering also changed

jpapadopoulos commented on 2014-02-02 13:17 (UTC)

lib32-libxshmfence seems to be a missing build dependency. It fails to build without it.

Krejzi commented on 2013-12-24 16:09 (UTC)

Adopted and updated the package to mirror the non-git package in [extra], enabled dri3 by default since there's a version of libxcb in [multlib-testing] which has the necessarry libraries. Report back if there are any issues.

oliv commented on 2013-12-12 10:55 (UTC)

Here are some changes I added to this package to build it correctly: # Maintainer: Jesse Jaara <gmail.com: jesse.jaara> # Contributor: Kristian Klausen <hotmail.com: klausenbusk> # Contributor: Egon Ashrafinia <gmail.com: e.ashrafinia> # Contributor: Tavian Barnes <gmail.com: tavianator> # Contributor: Jan de Groot <archlinux.org: jgc> # Contributor: Andreas Radke <archlinux.org: andyrtr> # Contributor: Thomas Dziedzic <gmail: gostrc> # Contributor: Antti "Tera" Oja <gmail.com: antti.bofh> # Contributor: Diego Jose <gmail.com: diegoxter1006> pkgbase=lib32-mesa-git pkgname=lib32-mesa-git # Dirty hack as AUR dont support split-packages # Take care of using mesa-git after all modules packages, because it copies all remaining install data true && pkgname=('lib32-ati-dri-git' 'lib32-intel-dri-git' 'lib32-nouveau-dri-git' 'lib32-svga-dri-git' 'lib32-mesa-git' 'lib32-mesa-libgl-git') pkgver=10.1.0_devel.60109 pkgrel=1 arch=('i686' 'x86_64') makedepends=('git' 'glproto' 'lib32-libdrm>=2.4.50' 'lib32-libxxf86vm' 'lib32-libxdamage' 'lib32-expat' 'lib32-libx11' 'lib32-libxt' 'gcc-multilib' 'dri2proto' 'python2' 'lib32-libxml2' 'imake' 'lib32-talloc' 'lib32-libvdpau' 'lib32-llvm' 'lib32-wayland' 'lib32-elfutils' 'libtool-multilib' 'gcc-multilib' 'bison' 'flex' 'llvm') url="http://mesa3d.sourceforge.net" license=('custom') options=(!libtool) source=('mesa::git+http://anongit.freedesktop.org/git/mesa/mesa.git#branch=master' LICENSE) md5sums=('SKIP' '5c65a0fe315dd347e09b1f2826a1df5a') pkgver() { cd "${srcdir}/mesa" echo $(cat VERSION | tr "-" "_").$(git rev-list --count HEAD) } _mesaver() { path="${srcdir}/mesa/VERSION" [ -f $path ] && cat "$path" } build() { export CC="gcc -m32" export CXX="g++ -m32" export PKG_CONFIG_PATH="/usr/lib32/pkgconfig" export LLVM_CONFIG="/usr/bin/llvm-config32" cd "${srcdir}/mesa" ./autogen.sh --prefix=/usr \ --sysconfdir=/etc \ --with-dri-driverdir=/usr/lib32/xorg/modules/dri \ --with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast \ --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \ --with-egl-platforms=x11,drm,wayland \ --with-llvm-shared-libs \ --enable-gallium-llvm \ --enable-egl \ --enable-gallium-egl \ --with-egl-platforms=x11,drm,wayland \ --enable-shared-glapi \ --enable-gbm \ --enable-glx-tls \ --enable-dri \ --enable-glx \ --enable-osmesa \ --enable-gles1 \ --enable-gles2 \ --enable-texture-float \ --enable-xa \ --enable-vdpau \ --disable-xvmc \ --disable-dri3 \ --enable-32-bit \ --libdir=/usr/lib32 make # fake installation mkdir -p "${srcdir}/fakeinstall" make DESTDIR="${srcdir}/fakeinstall" install } package_lib32-ati-dri-git() { pkgdesc="Mesa drivers for AMD/ATI Radeon" depends=('lib32-mesa-libgl-git' "lib32-mesa-git=${pkgver}" 'lib32-libvdpau') optdepends=('libtxc_dxtn: S3 Texture Compressed support') conflicts=('xf86-video-ati<6.9.0-6' 'lib32-ati-dri') provides=('lib32-ati-dri') # libvdpau_r300 is apparently not supported anymore install -m755 -d ${pkgdir}/usr/lib32/vdpau/ mv -v ${srcdir}/fakeinstall/usr/lib32/vdpau/libvdpau_{r600,radeonsi}.* ${pkgdir}/usr/lib32/vdpau/ install -m755 -d ${pkgdir}/usr/lib32/xorg/modules/dri mv -v ${srcdir}/fakeinstall/usr/lib32/xorg/modules/dri/{r200,r300,r600,radeon,radeonsi}_dri.so ${pkgdir}/usr/lib32/xorg/modules/dri/ install -m755 -d ${pkgdir}/usr/lib32/gallium-pipe mv -v ${srcdir}/fakeinstall/usr/lib32/gallium-pipe/pipe_{r300,r600,radeonsi}* ${pkgdir}/usr/lib32/gallium-pipe/ install -m755 -d "${pkgdir}/usr/share/licenses/ati-dri" install -m644 "${srcdir}/LICENSE" "${pkgdir}/usr/share/licenses/ati-dri/" } package_lib32-intel-dri-git() { pkgdesc="Mesa drivers for Intel" optdepends=('libtxc_dxtn: S3 Texture Compressed support') depends=('lib32-mesa-libgl-git' "lib32-mesa-git=${pkgver}") conflicts=("lib32-intel-dri") provides=("lib32-intel-dri") install -m755 -d ${pkgdir}/usr/lib32/xorg/modules/dri mv -v ${srcdir}/fakeinstall/usr/lib32/xorg/modules/dri/{i915,i965}_dri.so ${pkgdir}/usr/lib32/xorg/modules/dri/ install -m755 -d "${pkgdir}/usr/share/licenses/intel-dri" install -m644 "${srcdir}/LICENSE" "${pkgdir}/usr/share/licenses/intel-dri/" } package_lib32-nouveau-dri-git() { pkgdesc="Mesa drivers for Nouveau" optdepends=('libtxc_dxtn: S3 Texture Compressed support') depends=('lib32-mesa-libgl-git' "lib32-mesa-git=${pkgver}" 'lib32-libvdpau') conflicts=("lib32-nouveau-dri") provides=("lib32-nouveau-dri") install -m755 -d ${pkgdir}/usr/lib32/vdpau/ mv -v ${srcdir}/fakeinstall/usr/lib32/vdpau/libvdpau_nouveau.* ${pkgdir}/usr/lib32/vdpau/ install -m755 -d ${pkgdir}/usr/lib32/xorg/modules/dri mv -v ${srcdir}/fakeinstall/usr/lib32/xorg/modules/dri/nouveau_{dri,vieux_dri}.so ${pkgdir}/usr/lib32/xorg/modules/dri/ install -m755 -d ${pkgdir}/usr/lib32/gallium-pipe mv -v ${srcdir}/fakeinstall/usr/lib32/gallium-pipe/pipe_nouveau* ${pkgdir}/usr/lib32/gallium-pipe/ # vdpau drivers are still buggy with nouveau, so remove them (FS#36754) rm -rf ${pkgdir}/usr/lib32/vdpau/ install -m755 -d "${pkgdir}/usr/share/licenses/nouveau-dri" install -m644 "${srcdir}/LICENSE" "${pkgdir}/usr/share/licenses/nouveau-dri/" } package_lib32-svga-dri-git () { pkgdesc="Gallium3D VMware guest GL driver" depends=('lib32-gcc-libs' 'lib32-libdrm' 'lib32-expat' 'lib32-libffi') conflicts=("lib32-svga-dri") provides=("lib32-svga-dri") install -m755 -d "${pkgdir}"/usr/lib32/xorg/modules/dri mv -v "${srcdir}"/fakeinstall/usr/lib32/xorg/modules/dri/vmwgfx_dri.so \ "${pkgdir}"/usr/lib32/xorg/modules/dri/ install -m755 -d "${pkgdir}"/usr/lib32/gallium-pipe mv -v "${srcdir}"/fakeinstall/usr/lib32/gallium-pipe/pipe_vmwgfx* \ "${pkgdir}"/usr/lib32/gallium-pipe/ install -m755 -d "${pkgdir}/usr/share/licenses/${pkgname}" install -m644 "${srcdir}/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/" } package_lib32-mesa-git () { pkgdesc="an open-source implementation of the OpenGL specification" depends=('lib32-libdrm' 'lib32-llvm-libs' 'lib32-expat' 'lib32-libxxf86vm' 'lib32-libxdamage' 'lib32-systemd') optdepends=('opengl-man-pages: for the OpenGL API man pages') provides=("lib32-mesa=${_mesaver}" 'lib32-libglapi' 'lib32-osmesa' 'lib32-libgbm' 'lib32-libgles' 'lib32-libegl' 'lib32-khrplatform-devel') conflicts=('lib32-mesa' 'lib32-libglapi' 'lib32-osmesa' 'lib32-libgbm' 'lib32-libgles' 'lib32-libegl' 'lib32-khrplatform-devel') replaces=('lib32-libglapi' 'lib32-osmesa' 'lib32-libgbm' 'lib32-libgles' 'lib32-libegl' 'lib32-khrplatform-devel') mv -v "${srcdir}"/fakeinstall/* "${pkgdir}" # rename libgl.so to not conflict with blobs - may break gl.pc ? mv "${pkgdir}"/usr/lib32/libGL.so.1.2.0 "${pkgdir}"/usr/lib32/mesa-libGL.so.1.2.0 rm "${pkgdir}"/usr/lib32/libGL.so{,.1} rm -r "${pkgdir}"/usr/include rm "${pkgdir}"/etc/drirc install -m755 -d "${pkgdir}/usr/share/licenses/${pkgname}" install -m644 "${srcdir}/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/" } package_lib32-mesa-libgl-git () { pkgdesc="Mesa 3-D graphics library" depends=("lib32-mesa-git=${pkgver}") provides=("lib32-mesa-libgl=${pkgver}" "lib32-libgl=${pkgver}") conflicts=('lib32-mesa-libgl') # See FS#26284 install -m755 -d "${pkgdir}/usr/lib32/xorg/modules/extensions" ln -s libglx.xorg "${pkgdir}/usr/lib32/xorg/modules/extensions/libglx.so" ln -s mesa-libGL.so.1.2.0 "${pkgdir}/usr/lib32/libGL.so" ln -s mesa-libGL.so.1.2.0 "${pkgdir}/usr/lib32/libGL.so.1" ln -s mesa-libGL.so.1.2.0 "${pkgdir}/usr/lib32/libGL.so.1.2.0" install -m755 -d "${pkgdir}/usr/share/licenses/${pkgname}" install -m644 "${srcdir}/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/" }

Nowaker commented on 2013-08-20 19:02 (UTC)

missing 'lib32-mesa>=9.1' dependency for 'lib32-cairo' This package should provides=('lib32-mesa') I guess.

edoantonioco commented on 2013-08-04 01:10 (UTC)

Is this package the same than this? https://aur.archlinux.org/packages/mesa-git/

commented on 2013-08-01 14:25 (UTC)

@huulivoide I had to s/configure.ac/VERSION/g to allow for version number to come from the new standard name introduced in the 9.3 dev branch: http://cgit.freedesktop.org/mesa/mesa/commit/?id=488b3ed6f40df4608f7d02758ffd4ab7070c782e

sandy8925 commented on 2013-07-06 10:14 (UTC)

You are missing this line: rm -r ${pkgdir}/etc which is present in the multilib/lib32-mesa PKGBUILD

sandy8925 commented on 2013-07-06 10:10 (UTC)

Thank you. I was able to successfully compile and install with some trouble. Unfortunately the package installs /etc/drirc which is already available in the package mesa There shouldn't be any such conflict, especially with the main mesa package.

Huulivoide commented on 2013-07-05 10:57 (UTC)

sandy8925: You need to install lib32-talloc, lib32-libvdpau and lib32-wayland from the AUR first or use an AUR helper that can do it for you.

sandy8925 commented on 2013-07-05 08:55 (UTC)

Fails to build with: /usr/bin/makepkg: eval: line 2180: syntax error near unexpected token `(' /usr/bin/makepkg: eval: line 2180: `provides_list+=("lib32-ati-dri") provides_list+=("lib32-intel-dri") provides_list+=("nouveau-dri") provides_list+=("lib32-svga-dri") provides_list+=("lib32-mesa=$(cut -f-2 -d . <<< ${pkgver/_/-})" provides_list+=("lib32-mesa-libgl=$(cut -f-2 -d . <<< ${pkgver/_/-})"' ==> Making package: lib32-mesa-git 9.2.0_devel.57175-1 (Fri Jul 5 01:47:44 PDT 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Installing missing dependencies... [sudo] password for <user>: error: target not found: lib32-talloc error: target not found: lib32-libvdpau error: target not found: lib32-wayland

Lone_Wolf commented on 2013-06-17 12:26 (UTC)

package now uses llvm 3.3 from [extra] repo

kode54 commented on 2013-05-21 01:02 (UTC)

Here's an update which supports the new VCS changes, package version generation to be in line with the mesa-git package, lib32-nouveau-dri to actually provide lib32-nouveau-dri and not nouveau-dri, lib32-mesa-git to remove /etc/drirc and depend on mesa-git for it instead, llvm to detect and support any of several svn or git versions of llvm-amdgpu (the current git version of mesa requires version 3.3 or newer), and also adds support for applying patches from a patches directory. https://gist.github.com/kode54/5616795 I've also uploaded a single patch which is needed to use the current mesa-git against the current llvm-amdgpu-svn, which is LLVM version 3.4. https://gist.github.com/kode54/5616841

commented on 2013-05-19 17:41 (UTC)

You going to update this, to use the new VCS in pacman? http://allanmcrae.com/2012/08/changes-to-vcs-packaging-support-in-makepkg/

Lone_Wolf commented on 2013-04-16 21:18 (UTC)

Lord Heavy fixed lib32-elfutils and pulled it to multilib repo, so package can be build again.

Lone_Wolf commented on 2013-04-16 12:23 (UTC)

checking for elf_memory in -lelf... no configure: error: radeonsi and r600g require libelf when using LLVM lib32-elfutils is needed to solve this, but it doesn't build currently.

Lone_Wolf commented on 2013-04-09 14:53 (UTC)

adapted to pacman 4.1

Lone_Wolf commented on 2013-03-20 13:33 (UTC)

the bug was fixed upstream, patch removed

Lone_Wolf commented on 2013-03-18 21:00 (UTC)

added a patch to fix mesa bug 62434, see my mesa-r300-r600-radeonsi-git for details.

Lone_Wolf commented on 2013-03-10 21:24 (UTC)

corrected provides/conflicts

Lone_Wolf commented on 2013-03-09 17:02 (UTC)

Pacakage has switched from lvm-amdgpu-git which was build from tstellar's llvm tree to llvm-amdgpu-svn that is build from llvm master trunk. Also g3dvl is now enabled, this hopefully improves gpu acceleration for playing videos.

Lone_Wolf commented on 2013-02-20 22:03 (UTC)

Cleaned up dependencies, tried to build with wayland support but failed. a lib32-wayland version is needed for that.

Enverex commented on 2013-02-19 14:49 (UTC)

Looks like the dep for systemd-tools disappeared but I'm still getting: error: target not found: lib32-vdpau

Enverex commented on 2013-02-19 14:47 (UTC)

Can't build anymore due to a non-existant deps: error: target not found: lib32-systemd-tools error: target not found: lib32-vdpau

commented on 2013-02-19 07:58 (UTC)

I you not want to maintain this package i'm fresh to take over? I already maintain mesa-git :)

Lone_Wolf commented on 2013-02-04 21:14 (UTC)

build error has been fixed upstream, also cleaned up PKGBUILD a bit.

Lone_Wolf commented on 2013-01-29 21:17 (UTC)

Build currently fails with messages like these : /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ast_expr.o)' is incompatible with i386 output I've registered https://bugs.freedesktop.org/show_bug.cgi?id=60038 for this error.

Lone_Wolf commented on 2013-01-21 22:03 (UTC)

Package failed building, see https://aur.archlinux.org/packages/mesa-r300-r600-radeonsi-git/ for details

Lone_Wolf commented on 2013-01-13 22:29 (UTC)

Cleaned up PKGBUILD, corrected some dependencies

Lone_Wolf commented on 2013-01-05 21:37 (UTC)

Added radeonSI to configure options changed name of package This is the successor of my lib32-mesa-r600g-git package

Lone_Wolf commented on 2013-01-05 21:37 (UTC)

Added radeonSI to configure options changed name of package see https://aur.archlinux.org/packages/lib32-mesa-r300-r600-radeonsi-git for latest version

commented on 2012-12-14 09:40 (UTC)

Hullivoide: It seems to be easier now, as llvm have got merged amdgpu code http://www.phoronix.com/scan.php?page=news_item&px=MTI1MTI Now you could just edit clang-svn PKGBUILD and add "--enable-experimental-targets=AMDGPU", then you should have llvm with amdgpu and clang

Lone_Wolf commented on 2012-12-12 20:04 (UTC)

added lib32-llvm-amdgpu-git as makedepend

Huulivoide commented on 2012-12-11 22:40 (UTC)

Not really, and we have a bigger problem on the git side in general. Fo sometime now, the master tree has depended on the still in developpenment V3.2 of LLVM. And we do not have a git clang/llvm pkg yet.

commented on 2012-12-11 21:05 (UTC)

Huulivoide any update about libclang?

Lone_Wolf commented on 2012-10-15 21:29 (UTC)

- included resourceproto in makedepends - now provides/conflicts lib32-libgbm - added --enable-xa to configure flags - adapted leftout configure flags to current ./configure --help output

Lone_Wolf commented on 2012-09-19 09:57 (UTC)

That is because libglu is no longer part of mesa, but became a separate project. Install the aur packages lib32-libglu-git & libglu-git

commented on 2012-09-19 09:47 (UTC)

I tried play in Torchlight, but I got error: /usr/local/games/Torchlight/Torchlight.bin.x86_64: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory

Lone_Wolf commented on 2012-09-11 18:43 (UTC)

Added OpenGl ES 1 & ES 2 support

Lone_Wolf commented on 2012-08-26 22:32 (UTC)

Added !makeflags in options array due to build problems when compiling with multiple jobs had to add lib32-systemd-tools (successor of lib32-udev) as building failed with incompatible libudev.so messages without it. lib32-systemd-tools is also an aur package , and has a 3rd aur package lib32-kmod as a makedepend .

Lone_Wolf commented on 2012-07-18 13:44 (UTC)

removed lib32-udev from dependencies, build no longer gives warnings about incompatible udev/systemd-tools . Also added --enable-r600-llvm-compiler to congire flags.

Huulivoide commented on 2012-06-22 20:54 (UTC)

It will take a litle time to get this updated. I have made a ?working? lib32-systemd-tools package but it seems I need to make a lib32-clang package as well- I think I will rename it lib32-libclang as we don't need the actual compiler from it, just the genereal usefull libraries used by mesa's opencl implementation (if I' not cmpletely mistaken ^_^)....

Lone_Wolf commented on 2012-03-16 11:41 (UTC)

lib32-udev was a dependency when still in multilib , i removed it after it was moved to aur and the build did finish. Since there were some weird issues with lib32-mesa and wine, the change in lib32-llvm 3.0-2 triggered me to look deeper into the PKGBUILD. See https://bbs.archlinux.org/viewtopic.php?id=79509 (page 90). If you build without lib32-udev installed, there is a warning that the 64-bit libudev is not compatible and can't be used. also namcap on the package reported it as a needed dependency. Similar things happen with lib32-libvdpau. With the current PKGBUILD the issue with wine/warcraft 3 demo that was solved by Cdh by building with -j1 is gone, so it does seem worth it.

commented on 2012-03-15 22:53 (UTC)

Looks like lib32-libudev was missed when moving packages from multilib to aur. If I edit the PKGBUILD file to remove the dependency it builds. Would you know what libudev being used for (eg what is apt to be broken)? Building a few more packages is a bit of a pita, but its still much faster than gentoo was (a little more work though). Thanks for keeping this build up to date - its appreciated.

Lone_Wolf commented on 2012-03-14 18:20 (UTC)

Not sure, but llvm-config is in a different place (and has another name) then in lib32-llvm 3.0-1 . I've made a lot of changes in the PKGBUILD today, try again. Note : dependencies changed, and as several lib32-* pacakges were moved from multilib to AUR you'll have to build them yourself. the packages needed are lib32-udev lib32-libvdpau lib32-kmod

commented on 2012-03-14 12:12 (UTC)

I'm now getting: ./gallivm/lp_bld.h:54:2: error: #error "HAVE_LLVM should be set with LLVM's version number, e.g. (0x0207 for 2.7)" The 64 bit version works fine. multilib/lib32-llvm 3.0-2 is installed and lib32-libdrm-git. Ideas?

Lone_Wolf commented on 2012-02-14 21:18 (UTC)

NOTE : requires lib32-libdrm >= 2.4.31 , which is currently in multilib-testing repo.

commented on 2012-02-01 19:43 (UTC)

Google-Earth is working, so I'm satisfied. Thank you very much! If you don't mind me asking, why the cumbersome read-eval-print-loop? Don't these problems reproduce on your system?

Huulivoide commented on 2012-02-01 19:34 (UTC)

Fixed :DDD any more errors?

commented on 2012-02-01 19:04 (UTC)

$ tar -tf lib32-libglapi-git-20120201-2-x86_64.pkg.tar.xz .PKGINFO usr/ usr/lib32/ No shared library files in this package.

Huulivoide commented on 2012-02-01 18:36 (UTC)

Fixed...

commented on 2012-02-01 17:23 (UTC)

warning: cannot resolve "lib32-khrplatform-devel-git", a dependency of "lib32-libegl-git" :: The following package cannot be upgraded due to unresolvable dependencies: lib32-libegl-git I don't think "lib32-khrplatform-devel-git" exists. Then: :: lib32-libglapi-git and libglapi-git are in conflict (libglapi). Remove libglapi-git? [y/N] n error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: lib32-libglapi-git and libglapi-git are in conflict ==> WARNING: Failed to install built package(s).

Huulivoide commented on 2012-02-01 16:54 (UTC)

so the make -j1 didn't fix that then.... Well just comment out the rm build and cp... lines and rerun makepkg, it wil buil then

commented on 2012-02-01 16:52 (UTC)

make: *** No rule to make target `../../../../src/gallium/state_trackers/egl/libegl.a', needed by `../../../../lib32/egl/egl_gallium.so'. Stop. make: Leaving directory `/mnt/backup/home/backup/devel/lib32-mesa-git/src/build/src/gallium/targets/egl-static' ==> ERROR: A failure occurred in package_lib32-libegl-git(). Aborting...

Huulivoide commented on 2012-02-01 16:45 (UTC)

OK, should be OK now. Please test it

Huulivoide commented on 2012-02-01 15:31 (UTC)

t_zeev, please wait a ?hour?/till I get this updated... I orphanned this some time ago, but readopted this, as nobody else shows any interest.... IF there is someone interested and capable of maintaining this, please tell me. I my self am currently using the AMD's binary blob, but have been planning on chanhing back to OSS drivers, some time soon..., but for time being, Im going to maintain this "blindly"

commented on 2012-02-01 15:30 (UTC)

Thank you Huulivoide! lib32-mesa-git builds. But I thought the other packages should work too. I get: ==> Starting package_lib32-libgl-git()... Unknown type of argument: lib/libGL.so* ==> ERROR: A failure occurred in package_lib32-libgl-git(). Aborting... Should the other packages work too?

Huulivoide commented on 2012-02-01 15:09 (UTC)

You can pss -R to makepkg, sho it will skip the build() function...

commented on 2012-02-01 15:08 (UTC)

rm: cannot remove `/mnt/backup/home/backup/devel/lib32-mesa-git/pkg/lib32-mesa-git/usr/lib32/pkgconfig': Is a directory ==> ERROR: A failure occurred in package_lib32-mesa-git(). Aborting... if I change "rm -f" to "rm -rf" of pkgconfig and include, I get to another error. I'll post that when it finishes. Can I force makepkg to not start the build from the beginning?

Huulivoide commented on 2012-02-01 14:01 (UTC)

t_zeev, how does the install phase not work? Could you give us some more info. Seems there is no maintainer at the moment...

commented on 2012-02-01 10:04 (UTC)

Even with "export LLVM_CONFIG=/usr/lib32/llvm/llvm-config" (thanks!), after successful compile & link the build fails during install phase. Could the maintainer please verify the package builds for him? (and fix)

Lone_Wolf commented on 2012-01-10 23:42 (UTC)

Headers for EGL are now included, also builds the EGL state tracker. GLES 1 + 2 headers are not included, since the package is built without GLES support.

Lone_Wolf commented on 2012-01-06 19:00 (UTC)

There may be nothing wrong with that, but I use the mesa/lib32-mesa PKGBUILD in Extra as a template. Staying close to those helps with determining correct dependencies/conflicts.

haagch commented on 2011-12-27 15:01 (UTC)

I was wondering if there is a reason for the build function to be so complex. What's wrong with this: make make DESTDIR="${pkgdir}" install rm -rf "${pkgdir}"/usr/{include,share,bin}

Lone_Wolf commented on 2011-12-21 23:58 (UTC)

I'll look into it, but it may have to do with a problem in lib32-llvm . i suggest you try again with lib32-llvm 3.0 (in repo since tuesday evening i think)

commented on 2011-11-17 22:51 (UTC)

and lib32-udev

commented on 2011-11-17 22:37 (UTC)

And lib32-llvm should be one of the dependecies.

vodik commented on 2011-09-17 07:44 (UTC)

You need to add export LLVM_CONFIG=/usr/lib32/llvm/llvm-config otherwise it tries to use the 64bit llvm.

Lone_Wolf commented on 2011-09-14 09:10 (UTC)

Corrected

commented on 2011-09-13 14:48 (UTC)

This package only installs the library for the r300 driver. The "make install" for r600 is missing.

Lone_Wolf commented on 2011-09-12 18:59 (UTC)

updated

Lone_Wolf commented on 2011-07-16 21:22 (UTC)

Updated, now uses same compile settings as mesa-r600g-git

Lone_Wolf commented on 2011-07-15 00:18 (UTC)

lib32 packages create 32-bit binaries that work in a 64 bit environment. Wine, dwarffortress and zsnes are applications that need lib32-mesa libraries to run in 64 bit environment. If you have 1 of these on your system now : lib32-mesa / lib32-ati-dri / lib32-libgl , then install both mesa-r600g-git and lib32-mesa-r600g-git .

maddien commented on 2011-07-14 09:48 (UTC)

what's the difference to the non-lib32 version, which worked fine for me although I have multilib enabled? In short, which version should I use and why if I have a 64bit arch with multilib repo enabled?

Lone_Wolf commented on 2011-07-13 16:30 (UTC)

multilib counterpart for my mesa-r600-git package, https://aur.archlinux.org/packages.php?ID=47817 To build this, you will need dri2proto 2.6 or later, currently in testing.

Huulivoide commented on 2011-03-03 16:00 (UTC)

Updated to reflect the changes made in mesa-git.