Suppose that you do maintain your own llvm gcc/clang based C++ toolchain for your own product sdk and you need to target wide range of linux glibc based distros, then below small patch tips might be useful for you.
1. Get your own gcc/clang install from your distro and recent llvm version >=7 or you can build from source as usual .
2. Grab mesa 19.3.5 and extract it somewhere
3. Apply following patch or you can revert following git commit
diff -ENwbur mesa-19.3.5/src/util/os_file.c mesa19/src/util/os_file.c
--- mesa-19.3.5/src/util/os_file.c 2020-03-10 03:36:39.093724300 +0700
+++ mesa19/src/util/os_file.c 2020-04-10 22:07:09.103647279 +0700
@@ -34,7 +34,7 @@
#if defined(__linux__)
#include
-#include
+//#include
#include
#include
#include
@@ -135,9 +135,11 @@
bool
os_same_file_description(int fd1, int fd2)
{
- pid_t pid = getpid();
+ if (fd1 == fd2)
+ return true;
+
+ return false;
- return syscall(SYS_kcmp, pid, pid, KCMP_FILE, fd1, fd2) == 0;
}
#else
Linux kcmp syscall is only available since kernel 3.5, you can skip that execution and apply dummy simple integer comparation instead.
4. And perform build execution
meson -Dbuildtype=release -Dplatforms=x11 -Dshared-glapi=true -Dgles1=false -Dgles2=false -Dgbm=false -Dgallium-drivers=swrast -Ddri3=false -Dvulkan-drivers= build_dir
I’m not interested in targeting heavy high fps realtime 3d apps at the moment. Only llvmpipe and swrast backend cpu execution should enough for small 3d visualization apps, therefore some gpu vulkan drivers not currently being built.
As noted from the manual manpage, the lightweight approach might be to expose suitable process information via the proc(5) file system, and it does expose some unsuitable security implications.
Read More →