You are not logged in.
Those unknown functions all look like they come from mesa. The apitrace also mentions sdl2 many times.
Check https://wiki.archlinux.org/index.php/St … oting#XCOM
Especially the 2nd issue looks like it may be relevant.
I've checked this before with ldd. The only ones that are missing are provided by the Steam runtime (I believe, correct me if I'm wrong).
[user@desktop XCom-Enemy-Unknown]$ ldd binaries/linux/game.x86_64
linux-vdso.so.1 (0x00007fff4a7d0000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f7b052e3000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f7b052c2000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f7b052b8000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f7b052b3000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f7b05087000)
libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x00007f7b04e7e000)
libopenal.so.1 => /usr/lib/libopenal.so.1 (0x00007f7b04d7d000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f7b04b54000)
libsteam_api.so => not found
libicui18n.so.51 => not found
libicuuc.so.51 => not found
libicudata.so.51 => not found
libCoreFoundation.so.476 => not found
libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0x00007f7b04a09000)
libSDL2_image-2.0.so.0 => /usr/lib/libSDL2_image-2.0.so.0 (0x00007f7b049d6000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f7b04907000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f7b048c0000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f7b04730000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f7b045e8000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f7b045ce000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f7b04409000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f7b05547000)
libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f7b04202000)
libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f7b041ca000)
libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007f7b04133000)
libtiff.so.5 => /usr/lib/libtiff.so.5 (0x00007f7b040a8000)
libwebp.so.7 => /usr/lib/libwebp.so.7 (0x00007f7b04038000)
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f7b04025000)
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007f7b03f30000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f7b03ef4000)
libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007f7b03ee9000)
libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007f7b03e49000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f7b03c23000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f7b03afd000)
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007f7b03ad8000)
libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f7b03a63000)
I've reinstalled the two SDL libraries just as a sanity check. Here's the apitrace output after, looks to be the same https://dpaste.de/hEsu/raw.
Offline
Yes, the apitrace looks the same.
apitrace: redirecting dlopen("libGL.so.1", 0x102) from /home/user/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64/libSDL2-2.0.so.0
No idea if that means the game uses steam-runtime/pinned_libs_64/libSDL2-2.0.so.0 or is redirected to system library .
Could you try with stock mesa to verify whether llvm trunk / mesa trunk are causing this issue ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
[extra]mesa is a split package, but aur mesa-git isn't.
Basically with aur mesa-git you get everything in one package, while [extra]/mesa allows you to leave out some parts if you don't want/need them.
Having a single package reduces maintenance and makes switching from stable to mesa-git rather easy, though reverting back to stable can be tricky.
What's the usual process for reverting from mesa-git to extra/mesa? Happy to try it just not sure how to satisfy all of the required dependencies given that extra/mesa is split.
Offline
Danger, Will Robinson
Danger, Will Robinson
Read entire post carefully before executing
1. exit any graphical envionrment and login to a tty as root .
2. install llvm-libs & llib32-llvm-libs and mesa-demos .
3. remove lib32-mesa-git & mesa-git
pacman will refuse to do that, you'll have to force it by using --nodeps twice in the remove command .
warning : your graphics environment is now in very bad shape , don't use it until you are at step 6.
4. install mesa opencl-mesa vulkan-intel vulkan-radeon libva-mesa-driver mesa-vdpau
5. install lib32-mesa lib32-vulkan-intel lib32-vulkan-radeon lib32-libva-mesa-driver lib32-mesa-vdpau
6. start X
7. run glxinfo & glxinfo32 to verify basic mesa functionality.
Over the years I have done this myself 10+ times for troubleshooting and several times to verify the method still works , but it still is risky.
Unfortunately I have never found a better way.
This usecase is not suited for replaces imo, and pacman has no other method to combine removal and install in one action.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I've done that a few times without leaving the DE, it's a pain to do all this manually, but it's easy enough I think.
Offline
Okay now I'm very confused.
So I've sucessfully reverted back to Mesa 19.1.0 as per Lone_Wolf's guide.
[user@desktop ~]$ glxinfo | grep "OpenGL version"
OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.1.0
And it's still doing it. So it's not a regression.
Having said that, I'm getting the same weird Mesa errors from apitrace:
I just wanted to shoot aliens.
Offline
It does seem to be a steam issue. Try creating a separate thread to get the attention from other steam users.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
It does seem to be a steam issue. Try creating a separate thread to get the attention from other steam users.
Are you sure it's a Steam issue? If that were the case wouldn't it be broken for everyone in this thread and beyond? Same thing happens with the Steam beta client.
I was under the impression that there must be something wrong with my Arch install.
Offline
I should have been clearer and use "an issue with your steam installation" .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Did anything happen to @lordheavy 's repo? It seems empty now http://pkgbuild.com/~lcarlier/mesa-git/x86_64/ .
Offline
Did anything happen to @lordheavy 's repo? It seems empty now http://pkgbuild.com/~lcarlier/mesa-git/x86_64/ .
Yes, the build script is broken, so i'm waiting for the fix......
Offline
Oh I see, thanks for the quick reply!
Is this anything I can help with?
Offline
Oh I see, thanks for the quick reply!
Is this anything I can help with?
Alas no....
Offline
Some news from the mesa-git repo:
- amdvlk and lib32-amdvlk packages are now available
- a mesa-aco-git package is now available
Offline
Thank you for this!
Would it be possible to offer lib32-mesa-aco-git as well? Not that I need ACO for 32b apps, but it's not installable currently:
pacman -S mesa-aco-git
resolving dependencies...
looking for conflicting packages...
:: mesa-aco-git and vulkan-radeon-git are in conflict (vulkan-radeon). Remove vulkan-radeon-git? [y/N] y
:: mesa-aco-git and vulkan-mesa-layer-git are in conflict. Remove vulkan-mesa-layer-git? [y/N] y
:: mesa-aco-git and mesa-git are in conflict (mesa). Remove mesa-git? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: removing mesa-git breaks dependency 'mesa-git' required by lib32-mesa-git
:: removing vulkan-mesa-layer-git breaks dependency 'vulkan-mesa-layer-git' required by lib32-vulkan-mesa-layer-git
:: removing vulkan-radeon-git breaks dependency 'vulkan-radeon-git' required by lib32-vulkan-radeon-git
Offline
Thank you for this!
Would it be possible to offer lib32-mesa-aco-git as well? Not that I need ACO for 32b apps, but it's not installable currently:pacman -S mesa-aco-git
resolving dependencies...
looking for conflicting packages...
:: mesa-aco-git and vulkan-radeon-git are in conflict (vulkan-radeon). Remove vulkan-radeon-git? [y/N] y
:: mesa-aco-git and vulkan-mesa-layer-git are in conflict. Remove vulkan-mesa-layer-git? [y/N] y
:: mesa-aco-git and mesa-git are in conflict (mesa). Remove mesa-git? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: removing mesa-git breaks dependency 'mesa-git' required by lib32-mesa-git
:: removing vulkan-mesa-layer-git breaks dependency 'vulkan-mesa-layer-git' required by lib32-vulkan-mesa-layer-git
:: removing vulkan-radeon-git breaks dependency 'vulkan-radeon-git' required by lib32-vulkan-radeon-git
It's the next step; you can install packages from mutilib to workaround the problem
edit: lib32-mesa-aco-git is now available. Have fun
Last edited by lordheavy (2019-08-02 16:20:20)
Offline
Wow, that was quick!
Thank you!
Offline
@lordheavy I could be very wrong but I think the current mesa-git package does not provide usr/include/GL/gl.h anymore, is it supposed to be replaced by something else?
Last edited by gee (2019-10-18 10:24:39)
Offline
I had the same with my aur mesa-git package.
Mesa upstream decided to no longer provide those headers since recent glvnd versions provide them.
Unfortunately libglvnd from repos and aur liglvnd-git delete those headers.
See https://aur.archlinux.org/packages/mesa … ent-711429 and later comments for more info and workarounds.
Last edited by Lone_Wolf (2019-10-18 10:35:40)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thank you for the quick reply!
I suppose there is no good solution then. libglvnd cannot offer these until the mesa package stops doing so.
I guess I'll do the suggested rebuild of glvnd it should be easy enough, but maybe the repo should either offer glvnd-git or a small package in the meantime to provide those files?
edit: yup rebuilding took far less than a minute and was so easy.
Last edited by gee (2019-10-18 10:55:06)
Offline
@lordheavy I could be very wrong but I think the current mesa-git package does not provide usr/include/GL/gl.h anymore, is it supposed to be replaced by something else?
I will backport upstream patch in mesa, and restore headers in libglvnd in repos
Offline
Awesome, thank you!
Offline
Please test with libglvnd-1.2.0-3 in testing
Offline
Yup that works, thank you!
Offline
It seems that one or more of the latest packages in LH-mesa-git is unstable, causing audio glitches and system freezes for me (I'm using an RX 5700 XT). I wasn't able to pinpoint the issue, but downgrading everything as follows has fixed the issue for me:
mesa-git/clang-git 10.0.0_r330528.55eec2ba96b-1 -> 10.0.0_r330336.074af2daf5f-1
mesa-git/lib32-llvm-git 10.0.0_r330537.2a0fcae3d4d-1 -> 10.0.0_r330344.171cf5302f4-1
mesa-git/lib32-llvm-libs-git 10.0.0_r330537.2a0fcae3d4d-1 -> 10.0.0_r330344.171cf5302f4-1
mesa-git/lib32-mesa-git 1:19.3.0_devel.117047.ff6e148a3d6-1 -> 1:19.3.0_devel.116789.59127925010-1
mesa-git/lib32-vulkan-radeon-git 1:19.3.0_devel.117047.ff6e148a3d6-1 -> 1:19.3.0_devel.116789.59127925010-1
mesa-git/libclc-git 589.201910291654-1 -> 589.201910252019-1
mesa-git/llvm-git 10.0.0_r330528.55eec2ba96b-1 -> 10.0.0_r330336.074af2daf5f-1
mesa-git/llvm-libs-git 10.0.0_r330528.55eec2ba96b-1 -> 10.0.0_r330336.074af2daf5f-1
mesa-git/mesa-git 1:19.3.0_devel.117047.ff6e148a3d6-1 -> 1:19.3.0_devel.116789.59127925010-1
mesa-git/opencl-mesa-git 1:19.3.0_devel.117047.ff6e148a3d6-1 -> 1:19.3.0_devel.116789.59127925010-1
mesa-git/vulkan-radeon-git 1:19.3.0_devel.117047.ff6e148a3d6-1 -> 1:19.3.0_devel.116789.59127925010-1
Offline