cmake doesn't check for cpu_features library being installed

Question

cmake doesn't check for cpu_features library being installed

MattEttus opened this issue 2 years ago · comments

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

Johannes Demel · Answer 1 · Thu Oct 27 2022 15:28:33 GMT+0800 (China Standard Time)

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.

Miklos Maroti · Answer 2 · Thu Dec 22 2022 03:53:13 GMT+0800 (China Standard Time)

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.

Johannes Demel · Answer 3 · Sun Dec 25 2022 23:16:19 GMT+0800 (China Standard Time)

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.

Miklos Maroti · Answer 4 · Tue Dec 27 2022 18:11:23 GMT+0800 (China Standard Time)

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.

Johannes Demel · Answer 5 · Mon Jan 02 2023 20:17:02 GMT+0800 (China Standard Time)

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.

Johannes Demel · Answer 6 · Fri Sep 15 2023 16:09:51 GMT+0800 (China Standard Time)

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

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