Compiler – Fun with CLANG – Kernel, NVIDIA, and VMware…
I have been carrying out some preliminary tests to see how feasible it is to compile the Linux Kernel, and NVIDIA drivers, and VMware, using the ‘alternative’ to GCC – CLANG..
The kernel compile is relatively easy, and well documented:
# make CC=clang HOSTCC=clang -j8 (for a 4-core system)
The compile seems to be slower than GCC, but completes without problems, and boots/runs OK:
# uname -a
Linux rg400g4 5.11.10 #1 SMP Fri Mar 26 20:56:15 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux
I was able to get the latest NVIDIA driver to compile using:
# export CC=clang
# export CXX=clang++
# ./NVIDIA-Linux-x86_64-460.67.run -s --install-libglvnd
This worked, but gave a rather confused warning:
WARNING: Ignoring CC version mismatch:
The kernel was built with clang version 12.0.0 (Fedora
12.0.0-0.2.rc1.fc34), GNU ld version 2.35.1-41.fc34, but the
current compiler version is clang version 12.0.0 (Fedora
12.0.0-0.2.rc1.fc34).
Once again, the compile seemed to take longer than GCC, but completed successfully:
# lsmod |grep nv
nvidia_drm 61440 0
nvidia_modeset 1208320 1 nvidia_drm
nvidia 34009088 1 nvidia_modeset
drm_kms_helper 212992 1 nvidia_drm
drm
A manual compile from extracted !/NVIDIA-Linux-x86_64-460.67.run/kernel showed a large number of ‘warnings’:
# export CC=clang
# export CXX=clang++
# make
.............
/home/rgadsdon/NVIDIA-Linux-x86_64-460.67/kernel/nvidia-uvm/uvm_map_external.c:104:59: warning: implicit conversion from enumeration type 'const UvmGpuCachingType' to different enumeration type 'UvmRmGpuCachingType' [-Wenum-conversion]
pte_buffer->mapping_info.cachingType = map_rm_params->caching_type;
~ ~~~~~~~~~~~~~~~^~~~~~~~~~~~
<< repeated.. >>
.............
VMware was interesting, and the usual vmware-modconfig…. was confused, and failed as it could not find gcc, despite prior CC/HOSTCC exports to clang etc:
# vmware-modconfig --console --install-all
[AppLoader] GLib does not have GSettings support.
Failed to get gcc information....
This was due to the fact that it was still trying to find gcc, and was failing, as gcc was not specified..
(Just to confirm, the Fedora 34 gcc version – gcc 11.. – does work OK with the vmware-modconfig command, when compiling with gcc..)
The simplest workaround for this is to use the patched vmmon/vmnet source in the (current) vmware-host-modules-workstation-16.1.0 directory, and run:
# make CC=clang HOSTCC=clang followed by (su) #make install . I found that in this case separate # export CC=clang and # export HOSTCC=clang followed by # make failed, but the inline command did work..
The resulting system booted OK, and NVIDIA and VMware both ran successfully.
I was not able to detect any obvious performance issues, but the system was not stress tested at this time…. This was an interesting exercise, but I am going to stay with gcc, for the time being..
As a historical note, this was the first time I had compiled the Kernel without using ‘vanilla’ GCC, since the days – many years ago – when I had to use EGCS…
Robert Gadsdon. March 27th, 2021.
Yeah, RG, talking about fun 🙂 I did the same about a week ago but with the 5.12 development rc’s! Just some thoughts about 5.12 compilation: if you use make CC=clang HOSTCC=clang LLVM=1 LLVM_IAS=1 -j8 you will be able to use LTO as well… But you have to do this in every step i.e: make CC=clang HOSTCC=clang LLVM=1 LLVM_IAS=1 oldconfig (etc.). After the new .config is generated you’ll find some LTO entries in it… As I am using Ubuntu the nvidia drivers are built using ‘dkms’. I changed the LD part of dkms.conf to LD=/path/to/ld.lld and it worked compiling with clang! Also you could try using the environment variable IGNORE_CC_MISMATCH=1 which eliminates the CC mismatch warning (this is also from the dkms.conf).