I actually had some kind of crash related to exactly this library difference (base vs GCC) before, but I can't reproduce it right now. Wine is a bit special and tends to reveal very subtle differences. For C code they are fully* compatible and C++ dependencies Wine loads (openal-soft and various Mesa userspace graphics drivers) are actually compiled with Clang, so that the version of the library they would normally load without rpath interference. Now, should that be GCC's libgcc_s.so.1 rather than FreeBSD one? Not necessarily. It's also possible to remove this flag at compilation time, but that would be comparatively more annoying. To counteract rpath=/usr/local/lib/gcc10 field in i386 executables (this a Mk/ default, Wine itself doesn't set it), which makes the dynamic linker attempt to load a 64-bit version of the library which happens to be at that path on amd64.
$LOCALBASE/lib/libvulkan_radeon.so $I386_ROOT/$LOCALBASE/lib/libvulkan_radeon.so So, what we want is to add this line to wine, wine-devel and wine-proton (with appropriate revision bumps):ĭiff -git a/emulators/wine/files/wine-wow64.sh b/emulators/wine/files/wine-wow64.sh
0 kommentar(er)
