Fix make & cmake build errors on Arch Linux

[latekvo]

Fixes #307

Currently still being worked on.

• fixed errors in cmake
• fixed errors in make

[arthaud]

Unfortunately, it seems like version ranges in find_package are only available since CMake 3.19:
https://cmake.org/cmake/help/latest/command/find_package.html#basic-signature

We currently support cmake 3.4.3 and above, as specified by cmake_minimum_required:
https://github.com/NASA-SW-VnV/ikos/blob/master/analyzer/CMakeLists.txt#L41

We could potentially increase that, although there might be people depending on lower versions.
We could also have two versions of the find_package call depending on the cmake version.

[latekvo]

Removed version ranges in 5ab5b3a.

It looks like they were redundant, as FindLLVM.cmake returns the first LLVM version it finds, and it always begins it's search by looking for llvm-config-14.

[LynxesExe]

Unfortunately, it seems like version ranges in find_package are only available since CMake 3.19: https://cmake.org/cmake/help/latest/command/find_package.html#basic-signature

We currently support cmake 3.4.3 and above, as specified by cmake_minimum_required: https://github.com/NASA-SW-VnV/ikos/blob/master/analyzer/CMakeLists.txt#L41

We could potentially increase that, although there might be people depending on lower versions. We could also have two versions of the find_package call depending on the cmake version.

Hello!

I'm personally having issues with the cmake 3.4.3 requirement.
Modern CMake versions will output an error if the project being built is below a minimum requirement of CMake 3.5; this specifically is causing an issue when trying to install Ikos over brew in a GitHub runner.

For example by running this commands:

        cmake --version
        /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
        echo "$HOME/.linuxbrew/bin:$HOME/.linuxbrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin" >> $GITHUB_PATH
        echo >> /home/runner/.bashrc
        echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /home/runner/.bashrc
        eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
        brew install nasa-sw-vnv/core/ikos
        mkdir ikscan && pushd ikscan
        ikos-scan cmake .. -DCMAKE_POLICY_VERSION_MINIMUM=3.4.3 # <- Attempt at making it work anyway, I've tried both 3.4.3 and 3.5
        ikos-scan cmake build . --config Release
        popd

you end up with

# brew install
CMake Error at CMakeLists.txt:41 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.
  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
-- Configuring incomplete, errors occurred!
If reporting this issue please do so at (not Homebrew/brew or Homebrew/homebrew-core):
  https://github.com/nasa-sw-vnv/homebrew-core/issues
These open issues may also help:
Getting error while installing IKOS https://github.com/NASA-SW-VnV/homebrew-core/issues/19
Error: Process completed with exit code 1.

And the CMake Version in the runner is cmake version 3.31.6.

I've tried building IKOS and changing the minimum version to 3.5 and scan some test files... seems like everything is in order.

If upgrading to at least cmake_minimum_required(VERSION 3.5 FATAL_ERROR) could be considered it would be awesome!

[ivanperez-keera]

I would be ok with moving to at least 3.5, and I'd like to know what systems won't support 3.19.

[LynxesExe]

I'm not sure that I understand what systems you are referring to specifically, however if there is any checks I could that would be useful do let me know.

Purely out of curiosity I've bumped the CMake versions to 3.19 on all the CMake files and built everything from scratch; it worked just fine on my generic and up to date Debian VM.

[ivanperez-keera]

Is this ready to merge? Are any other changes needed?

[latekvo]

Hey, I apologize for abandoning this PR, I quite honestly forgot about it.

It's not ready to be merged yet, there were 2 separate issues: build error in cmake, and build error in make, with only the first one being fixed so far.

Regarding the make issues, i found that some distributions of llvm, upon running llvm-config --libs all return -lLLVM-<version-major>, and other return -lComponentA -lComponentB -lComponentC.
This is an issue, because the current CMakeLists.txt utilizes llvm_map_components_to_libnames, which will always output the per-component version of the llvm-config --libs <libraries> output, despite the installed LLVM distribution not necessarily accepting it.

I'm still figuring out how to determine if we should use the output generated by llvm_map_components_to_libnames versus just the simple -lLLVM-14, since this doesn't seem as simple as detecting the LLVM version...

I'll try to push a fix for this tomorrow, or when I find it

[latekvo]

Alternatively, I think we could also use:

execute_process(COMMAND llvm-config --libs <the libs> OUTPUT_VARIABLE output_variable)

but I think that requires the llvm-config executable to be available, and that has another set of issues:

• I'm not certain if llvm-config is always available, do you know if it's possible to import the LLVM headers without installing the executable? Couldn't find info on this, but that's an issue if it's possible. I'll continue searching
• When more recent LLVM versions are installed, we want to use llvm-config-14 instead of llvm-config, and that's another thing we'd have to detect.

[latekvo]

Excuse the spam, wanted to attach a closing note:

Replacing all instances of llvm_map_components_to_libnames with get_llvm_libraries, which is defined as following:

function(get_llvm_libraries llvm_store_var)
	set(${llvm_store_var} "-lLLVM-14" PARENT_SCOPE)
endfunction()

does fix all remaining issues that I have when building IKOS, but I'm quite sure this fix isn't universal to all user setups, and will likely break the make step for some (if not most) people.
This is due to forcing the usage of -lLLVM-14 instead of -lComponentA -ComponentB ....