Bug#935064: embree: FTBFS on x32 (assumes 64-bit size_t for __X86_64__)
Source: embree
Version: 3.5.0+dfsg-3
Tags: ftbfs
User: debian-x32@lists.debian.org
Usertags: x32
Dear Maintainers,
Embree lists architecture as 'any-amd64' as of 3.5.0+dfsg-3. This
causes it to be built under x32 (aka 'x32-gnu-linux-amd64').
The code seems to assume that 'unsigned [int]' is 32-bit and 'size_t'
is 64-bit on __X86_64__. Function definitions involving size_t are
guarded via #if defined(__X86_64__).
However, on x32 the address space is 32-bit, so 'size_t' (the maximum
size of an object/buffer) is 32-bit as well.
This results in build failures related to conflicting redefinitions in
common/sys/intrinsics.h and math/math.h for
embree::min/max/bsf/bscf/bsr for these types, e.g.
[ 1%] Building CXX object common/simd/CMakeFiles/simd.dir/sse.cpp.o
cd /<<BUILDDIR>>/embree-3.5.2+dfsg/build/common/simd && /usr/bin/c++
-DEMBREE_TARGET_AVX -DEMBREE_TARGET_AVX2 -DEMBREE_TARGET_SSE2
-DEMBREE_TARGET_SSE42 -DTASKING_TBB -Wall -Wformat -Wformat-security
-fPIE -fPIC -std=c++11 -fvisibility=hidden -fvisibility-inlines-hidden
-fno-strict-aliasing -fno-tree-vectorize -msse2 -o
CMakeFiles/simd.dir/sse.cpp.o -c
/<<BUILDDIR>>/embree-3.5.2+dfsg/common/simd/sse.cpp
In file included from /<<BUILDDIR>>/embree-3.5.2+dfsg/common/sys/sysinfo.cpp:18:
/<<BUILDDIR>>/embree-3.5.2+dfsg/common/sys/intrinsics.h:254:24: error:
redefinition of 'size_t embree::bsf(size_t)'
__forceinline size_t bsf(size_t v) {
^~~
/<<BUILDDIR>>/embree-3.5.2+dfsg/common/sys/intrinsics.h:244:26: note:
'unsigned int embree::bsf(unsigned int)' previously defined here
__forceinline unsigned bsf(unsigned v)
^~~
https://buildd.debian.org/status/fetch.php?pkg=embree&arch=x32&ver=3.5.2%2Bdfsg-2&stamp=1565263800&raw=0
[In fact it'd in be feasible for 'int' to be 64-bit and size_t to be 32-bit:
https://lists.gnu.org/archive/html/help-glpk/2017-05/msg00013.html
In practice I think both int and long are 32-bt on x32; indeed, long
unsigned int looks to the GCC definition of size_t. 'long long' as
used in common/simd/vint4_sse2.h is 64-bit.]
A workaround might be to use #if defined(__X86_64__) &&
!defined(__ILP_32__) to exclude the x32 platform where ints, longs and
pointers are 32-bit. Or, for Debian, exclude x32 from configuration.
However the underlying type assumptions seem to be flawed, and so the
best solution is probably to use size_t for its original purpose - the
maximum size of an object - and a clearly-defined 64-bit type like
'long long' (as specified in C99) for 64-bit integer operations.
If rendering kernels use assembly making similar assumptions about
64-bit/32-bit they will likely need adjusting to separate the sizing
of integer and pointer types, or risk either further compilation
failure or incorrect results.
GitHub appears to show suspect use of __X86_64__-guarded code in *at least*:
common/algorithms/parallel_sort.h (suspect shifts)
kernels/subdiv/tessellation_cache.h (mask size too big for a 32-bit size_t)
kernels/bvh/bvh.h (use of barriers should assert false on a 32-bit
size_t, but won't here)
kernels/geometry/grid_soa.h (assumes padding related to size of size_t
not required)
kernels/common/primref.h (masking and shift operations seeming to
assume 64-bit size_t)
common/sys/platform.h also sets ssize_t based solely on __X86_64__ but
since it's just for Windows it may be OK - unless they start to do
something different.
Best regards,
--
Laurence "GreenReaper" Parry
https://www.greenreaper.co.uk/
Reply to: