swrast_dri.so had an undefined reference to util_streaming_load_memcpy
on non-x86 archs.
Part of streaming-load-memcpy.c / libmesa_util_sse41.
When USE_SSE41 is not defined, memcpy() is used.
problem noticed at runtime on arm64 by mlarkin@
with and ok tb@
gkoehler mentioned running glxgears with the Mesa LLVMpipe driver
on macppc triggers an LLVM error
tested by matthieu@ (with a proposed Mesa 22.1 update) on macppc G4/400
lld can remove unused c++ sections from u_printf.cpp with --gc-sections
ld.bfd from binutils 2.17 can't unless this function is moved
u_printf_length() was added to u_printf.cpp upstream in
vulkan: Add vk_asprintf and vk_vasprintf helpers
2db5536a461734a818caf4f519e3286accb0818f
problem reported by deraadt@ and visa@ on sparc64 and octeon
link libmesa_util.a users with --gc-sections
avoids unwanted external references in shared libraries:
_ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE4findEcm
_ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv
_ZdlPv
_Znwm
__gxx_personality_v0
follows what the meson build does
problem reported by sthen@ when building sd2-ttf on i386
With Mesa 20.1 even after the kernel change to do wbinvd on all cpus
sthen@ reported that hard hangs still occurred on his Haswell system
with inteldrm.
Mark Kane also reported seeing hangs on Ivy Bridge on bugs@.
Some systems/workloads seem to be more prone to triggering this than
others as I have not seen any hangs on Ivy Bridge and the only hangs
I saw on Haswell when running piglit went away with the wbinvd change.
It seems something is wrong with drm memory attributes or coherency in
the kernel and newer Mesa versions expect behaviour we don't have.
While we no longer install .la files for Mesa naddy@ pointed out that
using libtool to build something like libGLU could result in .la files
which reference old Mesa .la files.
Remove Mesa .la files found in DESTDIR on install as suggested by
millert@
ok millert@ matthieu@ deraadt@
clang with -std=c99 generates warnings on typedef redefinition
likely unnoticed upstream as gcc does not do this
excessive amounts of warnings from vulkan driver headers pointed
out by deraadt@
