We notice that when libosmocore debian packages built on opensuse.org end up on the cumulus3 host, we get
/usr/src/packages/BUILD/tests/testsuite.dir/at-groups/9/test-source: line 25: 26402 Illegal instruction $abs_top_builddir/tests/conv/conv_gsm0503_test
(unfortunately I have no full logs, they were rotated away)
All other hosts we hit so far apparently work fine.
a) debian packages should be usable on the largest set of CPUs, we should not build with CPU instructions we can't guarantee to be supported. So I guess we need a --without-sse configure option in libosmocore. Makes sense?
b) I'm puzzled that the same host that built conv_gsm0503_test fails to run it. Is our SSE check in libosmocore's configure.ac broken? How to verify?
c) would be nice to find out what kind of host cumulus3 is; so far we know only that it is an x86_64. https://build.opensuse.org/monitor
Ideas? Experience?
~N
Hi Neels,
On Sat, Aug 12, 2017 at 04:36:48AM +0200, Neels Hofmeyr wrote:
a) debian packages should be usable on the largest set of CPUs, we should not build with CPU instructions we can't guarantee to be supported. So I guess we need a --without-sse configure option in libosmocore. Makes sense?
No, sorry. We are *compiling* code for various CPU instruction sets, and deciding at runtime, just like ffpmeg and many other projects with (optional) optimization, too.
b) I'm puzzled that the same host that built conv_gsm0503_test fails to run it. Is our SSE check in libosmocore's configure.ac broken? How to verify?
I'm not sure why you imply the assumption that the compiler capability to generate instructions for a certain CPU feature set should be related to the actual capability of the CPU to execute them.
You can always generate code that you cannot execute, this is quite normal.
c) would be nice to find out what kind of host cumulus3 is; so far we know only that it is an x86_64. https://build.opensuse.org/monitor
Can we somehow "cat /proc/cpuinfo" during the build and get the output of that? We could put this in the packaging rules or even in the makefile? Or even compile it into the binary with something like "-DCOMPILEHOST_CPUFLAGS=`cat /proc/cpuinfo`"
I've right now tested to build + make check libosmocore.git master on a very old x86_64 machine, one of the first processors ever to support the instructions set. Worked fine:
=== AMD Opteron 250 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow rep_good nopl extd_apicid
It could of course be that the packaging rules or the environment of OBS do something odd to the compiler optimization flags that would make an obs-built-binary behave different from a manually built one...
On Sat, Aug 12, 2017 at 09:29:14AM +0200, Harald Welte wrote:
You can always generate code that you cannot execute, this is quite normal.
er, of course. yes.
I've right now tested to build + make check libosmocore.git master on a very old x86_64 machine, one of the first processors ever to support the instructions set. Worked fine:
Did 'make check' also work?
Can we somehow "cat /proc/cpuinfo" during the build and get the output of that? We
@lynxis, can you ask / have you asked obs yet and/or can you sneak the cat /proc/cpuinfo in there? thx
~N
On Sun, Aug 13, 2017 at 01:59:05AM +0200, Neels Hofmeyr wrote:
I've right now tested to build + make check libosmocore.git master on a very old x86_64 machine, one of the first processors ever to support the instructions set. Worked fine:
Did 'make check' also work?
yes, obviosuly. Sorry for not pointing that out :)
-
Harald Welte -
Neels Hofmeyr