cmake doesn't check for cpu_features library being installed

[MattEttus]

Build fails with the following error if cpu_features not installed, which cmake should check:

Consolidate compiler generated dependencies of target volk_obj [ 88%] Built target volk_obj [ 89%] Linking C shared library libvolk.so /usr/bin/ld: cannot find -lcpu_features collect2: error: ld returned 1 exit status make[2]: [lib/CMakeFiles/volk.dir/build.make:168: lib/libvolk.so.2.5.2] Error 1 make[1]: [CMakeFiles/Makefile2:239: lib/CMakeFiles/volk.dir/all] Error 2 make: *** [Makefile:146: all] Error 2

[jdemel]

Well, CMake should check for cpu_features. Otherwise, this step should fail. In some cases CMake finds a cpu_features version that is not found by the linker. Do you use a custom prefix? I have seen cases where a previously installed cpu_features library was picked up erroneously. i.e. it might help to just delete the cpu_features file in your custom prefix install. I assume cpu_features is a submodule in your case.

[mmaroti]

I have seen this happen as well, and I think this is a bug probably in the cmake files. I think it is reproducible with the following steps:

• Make sure that libcpu-features-dev is not installed on your system
• Compile and install it with mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=/opt/test .. && make && make install
• Remove the build directory and try to do the exact same thing as before. This time the find_package(CpuFeatures QUIET) line in CMakeLists.txt will find the already installed package and will try to use that to compile itself, but will not be able to find the library when linking.
• You can recover by deleting the /opt/test/lib/cmake/CpuFeatures directory.

By the way, the QUIET flag is dangerous, as we have absolutely no feedback what is going on. At least when the library is found we should print out the CpuFeatures_DIR to the console to give some hint to the user what is going on. It would be better to disable looking for the library where it is going to be installed.

[jdemel]

So, the idea would be

• remove the QUIET option.
• Print the library path
• Disable ... I don't understand what you want to disable yet.

Your description sounds like there's a bug in the cpu-features CMake.

[mmaroti]

I am not sure about the fix, but I think the main problem is not in the cpu-features, but in the way cpu_features are discovered and used. Maybe the fix should be somehow disabling the search for the cpu_library in the CMAKE_INSTALL_PREFIX path. I have been playing around with that but not knowledgeable enough about cmake.

[jdemel]

Maybe we should reverse the order of discovery here. Check for a cpu_features submodule first, if not found, search for a system installation.

Playing with the CMAKE_INSTALL_PREFIX behavior seems dangerous. It might have all kinds of side-effects.

[jdemel]

cpu_features v0.9 was just released with this useful CMake option: https://github.com/google/cpu_features/pull/325 Switching to this new version should fix several issues.

1. The submodule cpu_features is not installed together with VOLK. That might fix the original issue
2. A VOLK install doesn't require a cpu_features install (we link privately and statically aginst the submodule).