mesa: 5f66b340aa49c6bc8d0acb2d1a6f8e9a7ef2cb2e (master) $ scons platform=windows toolchain=crossmingw winsys=gdi dri=no scons: Reading SConscript files ... Checking for C header file udis86.h... (cached) no warning: not building i915g warning: not building i965g warning: LLVM disabled: not building llvmpipe scons: done reading SConscript files. scons: Building targets ... scons: building associated VariantDir targets: build/windows-x86-debug Linking build/windows-x86-debug/gallium/targets/graw-null/graw.dll ... Creating library file: build/windows-x86-debug/gallium/targets/graw-null/libgraw.a build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_context.o): In function `p_atomic_dec_zero': src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4' build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_texture.o): In function `p_atomic_dec_zero': src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4' build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_tex_tile_cache.o): In function `p_atomic_dec_zero': src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4' build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_state_sampler.o): In function `p_atomic_dec_zero': src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4' build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_state_shader.o): In function `p_atomic_dec_zero': src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4' build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_state_surface.o):src/gallium/auxiliary/util/u_atomic.h:151: more undefined references to `___sync_sub_and_fetch_4' follow collect2: ld returned 1 exit status scons: *** [build/windows-x86-debug/gallium/targets/graw-null/graw.dll] Error 1
5f66b340aa49c6bc8d0acb2d1a6f8e9a7ef2cb2e is the first bad commit commit 5f66b340aa49c6bc8d0acb2d1a6f8e9a7ef2cb2e Author: Tom Fogal <tfogal@alumni.unh.edu> Date: Sun Sep 26 22:32:15 2010 -0600 Prefer intrinsics to handrolled atomic ops. :040000 040000 c8bc6dbb4983010591b2a72bd240c62757b0d914 3ed91977308b9039c9db7c9e06561aa4003a1a86 M src bisect run success
bugzilla-daemon@freedesktop.org writes: > https://bugs.freedesktop.org/show_bug.cgi?id=30514 > > mesa: 5f66b340aa49c6bc8d0acb2d1a6f8e9a7ef2cb2e (master) > > $ scons platform=windows toolchain=crossmingw winsys=gdi dri=no > scons: Reading SConscript files ... [snip] > src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to > `___sync_sub_and_fetch_4' Ahh, cross gcc must not support atomics. Not the best solution, but does the attached patch fix things?
Heh, my patch didn't come through email for some reason, but it was just a revert of the bisect you found :) I reverted it for now, since I need to run. Longer term, I think we should rely on intrinsics though, and somehow note when we've got a cross compiler that doesn't support these builtins (autoconf test?)
mesa: 113f1cdfcedf858e4b426ce2dba9e99d2a1e0286 (master) Verified fixed. SCons MinGW build passes.
As part of Nine patchset we also have this patch. By reading [1] I think it may still cause problems, maybe we could add glibc check and leave original INTRINSIC at his place --- a/src/gallium/auxiliary/util/u_atomic.h +++ b/src/gallium/auxiliary/util/u_atomic.h @@ -24,12 +24,12 @@ #define PIPE_ATOMIC_MSVC_INTRINSIC #elif (defined(PIPE_CC_MSVC) && defined(PIPE_ARCH_X86)) #define PIPE_ATOMIC_ASM_MSVC_X86 +#elif (defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 401) && defined( _GLIBCXX_ATOMIC_BUILTINS_4) +#define PIPE_ATOMIC_GCC_INTRINSIC #elif (defined(PIPE_CC_GCC) && defined(PIPE_ARCH_X86)) #define PIPE_ATOMIC_ASM_GCC_X86 #elif (defined(PIPE_CC_GCC) && defined(PIPE_ARCH_X86_64)) #define PIPE_ATOMIC_ASM_GCC_X86_64 #elif defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 401) #define PIPE_ATOMIC_GCC_INTRINSIC #else #error "Unsupported platform" #endif I'll send proper patch for testing at evening. [1] https://gcc.gnu.org/onlinedocs/gcc-4.6.0/libstdc++/manual/manual/bk01pt03ch28s02.html
patch is on ML [1]. Please retest and let me know, if it's for Windows builds OK :) Thank you [1] http://lists.freedesktop.org/archives/mesa-dev/2014-October/069503.html
What about, say, FreeBSD? Can't it use Gallium? Wouldn't this break it, then? The page you linked to mentions the define _GLIBCXX_ATOMIC_BUILTINS_4 is available when the implementation supports these. Maybe we should just key into that, instaed? We could probably delete the check for gcc then, even.
For _GLIBCXX_ATOMIC_BUILTINS_4 I tried to find it on my systems, did compile checks and it's nowhere to found (not sure if glibc dropped it or what) About FreeBSD -> I left original line at end, so it'll work as before.
This didn't fail to compile because of cross compiling. I think this failed to compile because gcc defaulted to -march=i386, which doesn't have the necessary instructions to implement the __sync_* intrinsics. I've resent a patch that prefers the intrinsics. -march=i386 is not a supported configuration.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.