[opensuse-buildservice] Possibility to pick OBS workers with specific hardware requirements
Hi, In the following project the cmake script probes for SSSE3 support in the compiler and refuses to build: [ 297s] -- Performing Test HAVE_SSSE3 - Failed [ 297s] CMake Error at 3rdParty/hyperscan/cmake/arch.cmake:23 (message): [ 297s] A minimum of SSSE3 compiler support is required [ 297s] Call Stack (most recent call first): [ 297s] 3rdParty/hyperscan/CMakeLists.txt:248 (include) The build randomly fails on some workers, works on others: Works: https://build.opensuse.org/package/live_build_log/home:andreas_baumann/strus... Doesn't work: https://build.opensuse.org/package/live_build_log/home:andreas_baumann/strus... So my suspission is that some workers run on old machines. My question: is there a way have special build tag like BuildRequires: worker_has_ssse3 to build packages - which require it - on never hardware? The other alternative I see is to use cross-compilation from SSSE3/non-SSSE3 hosts to SSSE3-hosts.. ..or of course to press "Trigger Rebuild" on failed builds till they find a more modern worker. ;-) Greetings Andreas -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 12/12/2016 08:58 AM, Andreas Baumann wrote:
My question: is there a way have special build tag like
BuildRequires: worker_has_ssse3
to build packages - which require it - on never hardware?
See
http://openbuildservice.org/help/manuals/obs-reference-guide/cha.obs.build_j...
Andreas
--
Andreas Stieger
On Montag, 12. Dezember 2016 08:58:12 CET Andreas Baumann wrote:
Hi,
In the following project the cmake script probes for SSSE3 support in the compiler and refuses to build:
[ 297s] -- Performing Test HAVE_SSSE3 - Failed [ 297s] CMake Error at 3rdParty/hyperscan/cmake/arch.cmake:23 (message): [ 297s] A minimum of SSSE3 compiler support is required [ 297s] Call Stack (most recent call first): [ 297s] 3rdParty/hyperscan/CMakeLists.txt:248 (include)
The build randomly fails on some workers, works on others:
*Compiler* support for SSSE3 (or any other CPU feature) is worker independent. Maybe Debian 8.0 lacks the specific compiler support. The bundled hyperscan requires SSSE3 (and optionally uses AVX2). Anyway, the resulting package will not run reliably on either i586 or x86_64, as the resulting binary will try to execute SSSE3 instructions independent of the current CPU. SSSE3 is available on most x86_64 CPUs, but not all. strus should use a runtime switch to select the best usable implementation, and fall back to a portable implementation otherwise. Crashing is not an option. Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Montag, 12. Dezember 2016, 12:51:31 CET wrote Brüns, Stefan:
On Montag, 12. Dezember 2016 08:58:12 CET Andreas Baumann wrote:
Hi,
In the following project the cmake script probes for SSSE3 support in the compiler and refuses to build:
[ 297s] -- Performing Test HAVE_SSSE3 - Failed [ 297s] CMake Error at 3rdParty/hyperscan/cmake/arch.cmake:23 (message): [ 297s] A minimum of SSSE3 compiler support is required [ 297s] Call Stack (most recent call first): [ 297s] 3rdParty/hyperscan/CMakeLists.txt:248 (include)
The build randomly fails on some workers, works on others:
*Compiler* support for SSSE3 (or any other CPU feature) is worker independent. Maybe Debian 8.0 lacks the specific compiler support.
right...
The bundled hyperscan requires SSSE3 (and optionally uses AVX2).
Anyway, the resulting package will not run reliably on either i586 or x86_64, as the resulting binary will try to execute SSSE3 instructions independent of the current CPU. SSSE3 is available on most x86_64 CPUs, but not all.
You can request such hardware via constraints and the cpu flags if needed btw.
strus should use a runtime switch to select the best usable implementation, and fall back to a portable implementation otherwise. Crashing is not an option.
yes, or build it multiple times and place it into the right subdirectories of %_libdir, so the runtime linker can decide to pick the right one. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Montag, 12. Dezember 2016 14:24:14 CET Adrian Schröter wrote:
On Montag, 12. Dezember 2016, 12:51:31 CET wrote Brüns, Stefan:
On Montag, 12. Dezember 2016 08:58:12 CET Andreas Baumann wrote:
Hi,
In the following project the cmake script probes for SSSE3 support in the compiler and refuses to build:
[ 297s] -- Performing Test HAVE_SSSE3 - Failed [ 297s] CMake Error at 3rdParty/hyperscan/cmake/arch.cmake:23 (message): [ 297s] A minimum of SSSE3 compiler support is required [ 297s] Call Stack (most recent call first): [ 297s] 3rdParty/hyperscan/CMakeLists.txt:248 (include)
The build randomly fails on some workers, works on others: *Compiler* support for SSSE3 (or any other CPU feature) is worker independent. Maybe Debian 8.0 lacks the specific compiler support.
right...
The bundled hyperscan requires SSSE3 (and optionally uses AVX2).
Anyway, the resulting package will not run reliably on either i586 or x86_64, as the resulting binary will try to execute SSSE3 instructions independent of the current CPU. SSSE3 is available on most x86_64 CPUs, but not all. You can request such hardware via constraints and the cpu flags if needed btw.
May be useful for running unit tests during package build, but does not help for the generated code.
strus should use a runtime switch to select the best usable implementation, and fall back to a portable implementation otherwise. Crashing is not an option.
yes, or build it multiple times and place it into the right subdirectories of %_libdir, so the runtime linker can decide to pick the right one.
Two problems (according to ld.so man page): - 32bit only on x86_64 - only defined for up to sse2, not (S)SSE3, AVX, ... Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Monday 2016-12-12 15:23, Brüns, Stefan wrote:
and fall back to a portable implementation otherwise. Crashing is not an option.
yes, or build it multiple times and place it into the right subdirectories of %_libdir, so the runtime linker can decide to pick the right one.
Two problems (according to ld.so man page): - only defined for up to sse2, not (S)SSE3, AVX, ...
Because the number of combinations explodes quickly, so this is infeasible. The two modern methods are 1. GNU indirect functions (ifunc) - http://willnewton.name/uncategorized/using-gnu-indirect-functions/ 2. function MV - https://gcc.gnu.org/wiki/FunctionMultiVersioning They require more source edits than just compile-and-ship-in-different-dirs, yeah :-/ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (5)
-
Adrian Schröter -
Andreas Baumann -
Andreas Stieger -
Brüns, Stefan -
Jan Engelhardt