You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Downstream in Gentoo, we received a report of a failed ispc build when running on a 'no multilib' profile (essentially an amd64 system which doesn't build 32-bit binaries by choice).
For now, I've worked around this by changing this when we're in such an environment:
if ("${bit}" STREQUAL "32" AND ${arch} STREQUAL "x86")
- set(target_arch "i686")
+ return()
elseif ("${bit}" STREQUAL "64" AND ${arch} STREQUAL "x86")
set(target_arch "x86_64")
From what I can tell, there isn't a way to disable i686 support via a CMake option directly.
Could you advise if there are any better methods to disable an i686 build on hardware (where the autodetection rightly thinks it is safe/capable of running it)?
Thank you!
The text was updated successfully, but these errors were encountered:
Heh, that's an interesting request. This is probably the first time people ask to disable 32-bit support in ISPC. Note, that this is not about host platform, but about target platform. We don't have a way to do that. But disabling it on the platforms that do not support 32 bits it does make sense.
But this request also means that you are using "standard" clang/llvm build, instead of recommended custom build with set of patches. Is there a chance to use our scripts to build LLVM? The set of patches that we are using are required for stability and all of them are backports from LLVM trunk.
Hi,
Downstream in Gentoo, we received a report of a failed ispc build when running on a 'no multilib' profile (essentially an amd64 system which doesn't build 32-bit binaries by choice).
For now, I've worked around this by changing this when we're in such an environment:
From what I can tell, there isn't a way to disable i686 support via a CMake option directly.
Could you advise if there are any better methods to disable an i686 build on hardware (where the autodetection rightly thinks it is safe/capable of running it)?
Thank you!
The text was updated successfully, but these errors were encountered: