Fix building the test application on non-x86 machines

[sicherha]

I maintain the Fedora Linux package for the blake3 C library.

On anything other than x86, make -f Makefile.testing fails due to undefined symbols:

/usr/bin/ld: /tmp/ccojePfa.o: in function `main':
main.c:(.text.startup+0x758): undefined reference to `get_cpu_features'
/usr/bin/ld: main.c:(.text.startup+0x75c): undefined reference to
`g_cpu_features'
/usr/bin/ld: main.c:(.text.startup+0x760): undefined reference to
`g_cpu_features'
/usr/bin/ld: main.c:(.text.startup+0xcfc): undefined reference to
`g_cpu_features'
/usr/bin/ld: main.c:(.text.startup+0xd00): undefined reference to
`g_cpu_features'
collect2: error: ld returned 1 exit status
make: *** [Makefile.testing:50: all] Error 1

The regression was introduced by commit
34d293e.

Here is how the two affected symbols, g_cpu_features and get_cpu_features(), are used in the different configurations.

IS_X86	BLAKE3_TESTING	Use of symbols
X		internal
X	X	internal & external
		N/A
	X	external

[oconnor663]

Thanks for the detailed report, particularly the responsible commit. This change looks reasonable. The bigger question to me is whether we want to add Makefile.testing to CI or just remove it. @BurningEnlightenment the same test.py file is now exercised by the cmake_c_tests CI job, correct? I should admit that when I'm working on the C code, my personal workflow is usually cd c/blake3_c_rust_bindings && cargo test.

[BurningEnlightenment]

yes, CMake executes test.py as part of cmake_c_tests. So removing Makefile.testing wouldn't reduce coverage. On that note, I still need to refactor and integrate #472