@kogasa
I was adding the patch but noticed it's already applied upstream. So no need to do anything here.
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) |
@kogasa
I was adding the patch but noticed it's already applied upstream. So no need to do anything here.
missing-include.patch
from mesa-git
is necessary and sufficient to build with llvm 15.
@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
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.
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.
@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.
@sir_randomuser
Thanks for reporting this. I'll look into it today.
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'
@Billli11,
Thanks for the report. PKGBUILD updated to use llvm 13.0.1
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.
EDITED
i'm sorry, something was wrong on my side probably, i tried again and it worked normally.
@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,
packages in depends=() don't have to be in makedepends=()
Mesa classic drivers removed. Removed drivers are Radeon R100 and R200, old (non-gallium) Nouveau, and Intel i915 and i965.
@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.
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.
PKGBUILD updated to use llvm 13.0.0
The time has come for me to transfer ownership of this package to Reza and step down as maintainer.
Lone_Wolf
swrast & virtio-experimental added to vulkan-drivers
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.
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
Removed the patch from the PKGBUILD. It should be fine now.
Thanks,
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 .
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.
@ronoverdrive,
I applied the patch used for lib32-llvm-minimal-git. Thanks to Lone_Wolf for providing the patch.
I haven't tested this with llvm-minimal-git recently. I'll give it a try.
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.
Crocus gallium driver added to the PKGBUILD.
PKGBUILD updated to use llvm 12.0.0
The default branch is now main instead of master in the upstream. PKGBUILD updated to point to the main.
PKGBUILD updated to reflect the change in meson vulkan-layers options. Also the wrong commit from the last night has been reverted.
I have switched to another package and am looking for a new maintainer.
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
Can ndbebug=true be re-enabled for this one too?
@Lone_Wolf
Here are the build logs. https://pastebin.com/9vDuLrVx (build) / https://pastebin.com/TDFdgiVY (package)
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.
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”.
Is “lib32-systemd” really a dependency for mesa? It’s not for the 64bit version, so it kind of doesn’t make any sense.
Both archlinux and mesa bugtrackers don't show LTO related problems with mesa afaik.
Re-enabled LTO.
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
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.
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.
@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.
@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.
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 ?
I haven't touched llvm, it is the 10.0.0-1 repo package
@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 ?
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
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
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 ?
Sinatosk, LordHeavy thanks for the info.
I'll disable zstd for this package until this has been solved.
@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
some possible causes
unset MESA_WHICH_LLVM
before makepkg ?@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.
Nowhere in the PKGBUILD do i use <9.1 or >= 9.0.0 .
Have you tried with a fresh git clone ?
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
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.
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.
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.
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 ).
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
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.
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.
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.
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 ?
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)
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?
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.
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
$
I think zink
can be added, it builds and runs just fine for me, with both stable and minimal-git llvm.
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.
Can we get zink
for lib32 too?
Done, thanks for the alert Demize.
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.
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/
Files like /etc/OpenCL/vendors/mesa.icd and /usr/include/* are conflicting with mesa-git. Is this intentional?
@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
This package now uses an environment variable to determine which llvm package it will be built against. Check PKGBUILD for details.
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.
Bug report for the vulkan overlay layer option https://bugs.freedesktop.org/show_bug.cgi?id=110606
vulkan-overlay-layer gives a build failure, for now that option is disabled.
Will try to register a bug report for it this weekend
Switched to lib32-llvm-lw-git and associated packages for llvm trunk master.
Instructions to use other llvm trunk versions will be posted soon.
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.
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
@Lone_Wolf Happy to hear about this update! :) Thanks again!
I've almost finished rewriting llvm-git, will start on lib32-llvm-git soon and then adjust lib32-mesa-git when needed.
Which of the 3 options did you try :
All 3 should have/provide lib32-llvm-svn & lib32-llvm-libs-svn
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.
will do that in next version this weekend
Please, add glslang
as dep here too.
Please add 'iris' to the list of gallium drivers.
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 ?
Why is lib32-opencl-mesa disabled actually? Is it not possible to build it?
looks like I forgot to remove the provides/conflicts for it, will correct it in next version.
@Lone_Wolf
Package advertises provision of lib32-opencl-mesa, but it's disabled in meson config.
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.
For it to build in a clean chroot, I've needed to add 'lib32-libva' and 'lib32-libxrandr' to makedepends.
@Lone_Wolf: this has been fixed in mesa, see https://cgit.freedesktop.org/mesa/mesa/commit/?id=1f41104b9bab50652050bf4524f2b9f371f7ca9b
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.
There are now some locale files conflicting with mesa-git too: https://gist.github.com/benoit-pierre/4e0a4f63513d81c8a7a0ca3ff57dba9c
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.
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)
Thanks for a quick fix, removing the packages wasn't needed, keep up being an awesome maintainer ^^
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 .
https://bugs.archlinux.org/task/58725
Can't do a -Syu because this package needs a patch ^^
Thanks, works now (after radv got fixed).
added valgrind as new makedepend
confirmed, looks like mesa-git now needs valgrind installed to correctly detect libdrm version. Investigating
Build fails with "configure: error: Direct rendering requires libdrm >= 2.4.75" despite 2.4.91 installed (also lib32).
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.