gallium tests fail to link with mesa-18.3.0 and 18.3.1. I can't find anything that obviously changed to break it between 18.2.6 and 18.3.1, at least in the build system -- code added u_cpu_detect.c that has another call to call_once, which might now be implicitly needed by tests, while add_to_atexit_list maybe wasn't needed before. It is suspect that -pthread is missing from these g++ calls, despite mesa_util stuff referencing it in meson.build. Maybe only gl_priv_libs has what's necessary? Some unrelated parts of my system aren't fully up to date, but if that's the problem, then it'd mean we have missing minimum deps here or something instead, but I don't think this can be the case. It feels like a build system bug, and just not many build tests with gallium or something? git master fails the same for me, when same meson configuration is used. FAILED: src/gallium/tests/trivial/quad-tex x86_64-pc-linux-gnu-g++ -m32 -o src/gallium/tests/trivial/quad-tex 'src/gallium/tests/trivial/src@gallium@tests@trivial@@quad-tex@exe/quad-tex.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group src/util/libmesa_util.a src/gallium/auxiliary/libgallium.a src/gallium/auxiliary/pipe-loader/libpipe_loader_dynamic.a src/loader/libloader.a src/util/libxmlconfig.a /usr/lib32/libz.so -lm -Wl,--end-group /usr/lib32/libdrm.so -L/usr/lib64/llvm/7/lib32 -lLLVMAMDGPUDisassembler -lLLVMAMDGPUCodeGen -lLLVMipo -lLLVMInstrumentation -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMAMDGPUAsmParser -lLLVMAMDGPUDesc -lLLVMAMDGPUInfo -lLLVMAMDGPUAsmPrinter -lLLVMAMDGPUUtils -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMTarget -lLLVMAnalysis -lLLVMProfileData -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMCore -lLLVMBinaryFormat -lLLVMSupport -lLLVMDemangle -ldl -lm /usr/lib32/libexpat.so -lm -O2 -pipe -march=native -fno-omit-frame-pointer -ggdb -frecord-gcc-switches -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: src/util/libmesa_util.a(u_cpu_detect.c.o): in function `call_once': /tmp/portage/media-libs/mesa-18.3.1/work/mesa-18.3.1-abi_x86_32.x86/../mesa-18.3.1/src/../include/c11/threads_posix.h:96: undefined reference to `pthread_once' collect2: error: ld returned 1 exit status [1291/1346] /usr/bin/python3.6 /usr/lib64/python-exec/python3.6/meson --internal symbolextractor src/gallium/targets/graw-null/libgraw_null.so 'src/gallium/targets/graw-null/src@gallium@targets@graw-null@@graw_null@sha/libgraw_null.so.symbols' --cross-host=linux [1292/1346] x86_64-pc-linux-gnu-g++ -m32 -o src/gallium/tests/trivial/tri 'src/gallium/tests/trivial/src@gallium@tests@trivial@@tri@exe/tri.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group src/util/libmesa_util.a src/gallium/auxiliary/libgallium.a src/gallium/auxiliary/pipe-loader/libpipe_loader_dynamic.a src/loader/libloader.a src/util/libxmlconfig.a /usr/lib32/libz.so -lm -Wl,--end-group /usr/lib32/libdrm.so -L/usr/lib64/llvm/7/lib32 -lLLVMAMDGPUDisassembler -lLLVMAMDGPUCodeGen -lLLVMipo -lLLVMInstrumentation -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMAMDGPUAsmParser -lLLVMAMDGPUDesc -lLLVMAMDGPUInfo -lLLVMAMDGPUAsmPrinter -lLLVMAMDGPUUtils -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMTarget -lLLVMAnalysis -lLLVMProfileData -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMCore -lLLVMBinaryFormat -lLLVMSupport -lLLVMDemangle -ldl -lm /usr/lib32/libexpat.so -lm -O2 -pipe -march=native -fno-omit-frame-pointer -ggdb -frecord-gcc-switches -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu FAILED: src/gallium/tests/trivial/tri x86_64-pc-linux-gnu-g++ -m32 -o src/gallium/tests/trivial/tri 'src/gallium/tests/trivial/src@gallium@tests@trivial@@tri@exe/tri.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group src/util/libmesa_util.a src/gallium/auxiliary/libgallium.a src/gallium/auxiliary/pipe-loader/libpipe_loader_dynamic.a src/loader/libloader.a src/util/libxmlconfig.a /usr/lib32/libz.so -lm -Wl,--end-group /usr/lib32/libdrm.so -L/usr/lib64/llvm/7/lib32 -lLLVMAMDGPUDisassembler -lLLVMAMDGPUCodeGen -lLLVMipo -lLLVMInstrumentation -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMAMDGPUAsmParser -lLLVMAMDGPUDesc -lLLVMAMDGPUInfo -lLLVMAMDGPUAsmPrinter -lLLVMAMDGPUUtils -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMTarget -lLLVMAnalysis -lLLVMProfileData -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMCore -lLLVMBinaryFormat -lLLVMSupport -lLLVMDemangle -ldl -lm /usr/lib32/libexpat.so -lm -O2 -pipe -march=native -fno-omit-frame-pointer -ggdb -frecord-gcc-switches -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: src/util/libmesa_util.a(u_cpu_detect.c.o): in function `call_once': /tmp/portage/media-libs/mesa-18.3.1/work/mesa-18.3.1-abi_x86_32.x86/../mesa-18.3.1/src/../include/c11/threads_posix.h:96: undefined reference to `pthread_once' collect2: error: ld returned 1 exit status
The problem went away after meson got upgraded from 0.47.1 to 0.48.2 - should upstream and us depend on that version, or can it be made to work with older meson too (for upstream to support building with older meson for enterprise distros or so)? Or something else wonky going on, or a temporary 0.47.1 regression, or...
With meson-0.47.1 -pthread is not passed to those failing compiler calls, and with meson-0.48.2 it is
Created attachment 557674 [details] build.log with meson-0.47.1 (fail)
Created attachment 557676 [details] build.log with meson-0.48.2 (success) For our purposes, I guess just raising meson dep would be fine (or telling I'm some corner case and do nothing), but upstream handling is more interesting maybe. I don't have the motivation/energy to go upstream myself right now, though, and some of this might be related to this crossfile stuff of ours somehow maybe.
I have different USE flags (no gallium or test) but mesa 18.3.2 is failing to link for me due to undefined references too; different symbols, mind you, for example: .../ccKmnS0C.ltrans1.ltrans.o: In function `dri2Flush.constprop.6': <artificial>:(.text+0xe86): undefined reference to `glFlush' and several more. That's using meson 0.48.2; I'll experiment with using a more recent version. Maybe the same underlying problem, maybe not.
Well, same result for meson 0.49.1. I'll open a new bug, although it might turn out to be the same thing.
(In reply to Mart Raudsepp from comment #4) > Created attachment 557676 [details] > build.log with meson-0.48.2 (success) > > For our purposes, I guess just raising meson dep would be fine (or telling > I'm some corner case and do nothing), but upstream handling is more > interesting maybe. I don't have the motivation/energy to go upstream myself > right now, though, and some of this might be related to this crossfile stuff > of ours somehow maybe. meson.eclass now has MESON_DEPEND=">=dev-util/meson-0.48.2" so I think we're good here.
