llvm on CentOS 7

[Chris Johns]

On 17/9/19 12:36 am, Joel Sherrill wrote:
> Running log as I work through this.

Thanks, it is appreciated.

> Build failed because I didn't have cmake. Double-checked and sb-check wouldn't
> have reported this. Not sure we should report it missing unless we can designate
> something as "needed by some packages" or let folks know which one(s).

Cmake is tagged as optional as llvm is optional.

The __cmake define in source-builder/defaults.mc could be changes to remove the
absolute path and the environment's path will be searched. This is already done
in FreeBSD, MacOS and I think Windows so maybe this should be the default.

> Loaded cmake, then got this beauty:
> 
> /usr/bin/cmake -Wno-dev -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release
> -DCMAKE_INSTALL_PREFIX=/home/joel/rtems-work/tools/5
> '-DPACKAGE_VERSION=8.0.1 (RTEMS 5, RSB
> 4b7af073000d612b21b9dece538d2bcc85c0c240)'
> -DLLDB_CODESIGN_IDENTITY=llvm ../llvm-8.0.1
> -- Configuring incomplete, errors occurred!
> CMake Error at CMakeLists.txt:3 (cmake_minimum_required):
>   CMake 3.4.3 or higher is required.  You are running version 2.8.12.2
> 
> Plenty of people on the net say to download and build it but it turns
> out that EPEL
> has a cmake3 RPM. That's a very respectable repo (unlike Ghettoforge which also
> had it).
> 
> yum erase cmake
> yum install cmake3
> 
> That installed /usr/bin/cmake3 which the build doesn't know about so I
> symbolically
> linked /usr/bin/cmake3 to ${HOME}/bin/cmake.
> 
> This didn't work because it checks for /usr/bin/cmake so I made that
> symlink to cmake3.

If this is needed for a specific CentOS version I suggest you detect this in
source-builder/sb/linux.py and set __cmake to cmake3. The llvm references
%{__cmake}. I would prefer this over documenting symlinks.

> This resulted in a failure further along.
> 
> -- Detecting CXX compile features - done
> CMake Error at cmake/modules/CheckCompilerVersion.cmake:40 (message):
>   Host GCC version should be at least 5.1 because LLVM will soon use new C++
>   features which your toolchain version doesn't support.  Your version is
>   4.8.5.  You can temporarily opt out using
>   LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN, but very soon your toolchain won't be
>   supported.
> Call Stack (most recent call first):
>   cmake/modules/CheckCompilerVersion.cmake:45 (check_compiler_version)
>   cmake/config-ix.cmake:13 (include)
>   CMakeLists.txt:590 (include)
> 

Ouch.

> -- Configuring incomplete, errors occurred!
> See also "/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/build/CMakeFiles/CMakeOutput.log".
> shell cmd failed: /bin/sh -ex
> /home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/do-build
> error: building rtems-llvm-8.0.1-x86_64-linux-gnu-1
> 
> Looks like I need to move to a machine with newer gcc. There is a
> floor on the host environment without doing some work. I think the
> CentOS machine I use to do test builds of our tools from
> gcc/binutils/newlib master should work since it has installs of
> various newer gcc.
> 
> That may take until I get home.

Again thanks.

FYI Windows with MSYS2 is not bilding even after upgrading it to latest packages
and installing clang-8.0.2 as a package to build clang-8.0.2 with.

On Windows the unpacking of the source has proved problematic because the cfe
tarball contains links to files that are extracted after the link and on Windows
that fails, the target needs to exist. I have added support to the RSB to handle
this however the testsuite contains a bad link to a non-existent target for
testing and this means the untar always fails. I have added a work around to the
RSB for this but it is a little painful.

I think this highlights there is a reasonable amount of work to get LLVM and
clang building on all hosts. On the other hand MSYS2 is like other packaging
systems, it provides clang-8.0.2 and it is built with all targets. Our users can
then decide to use the packaged LLVM or build from source.

Chris