Prior to commit 97e9593070a80b408f7e87af2c277f7abf885d51 on 4.20 branch I was able to use whichever LLVM/Clang version I have installed on my system (e.g. 6.0.0, or 5.0.1) for building UE 4.20 and my own projects. That commits forces installation of a bundled Clang at version 5.0.0.
So, since I have third-party libraries built using Clang 6.0.0, is there any way to tell UBT to use a different Clang other than the bundled one, without reverting that commit or modifying the engine files?
This might give you a hint:
UBT checks all possible clang shell commands and use first found on the list… so i guess simple solution is simply deleting clang in UE4 or simple don’t path it in evrnament varables. “clang” will always be picked first so that one will be used with top proprity.
You can always modify UBT code if you like.
Thank you for the detailed answer and the GitHub link. Unfortunately, deleting the bundled compiler makes UBT complain about not finding it; so, the build fails.
I get the following on my system:
$ which clang++
/usr/lib/llvm/6/bin/clang++
$ echo $PATH
/home/babaei/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0:/usr/lib/llvm/6/bin:/usr/lib/llvm/5/bin:/opt/cuda/bin
$ clang++ --version
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm/6/bin
Unfortunately, UBT won’t pick up that. But, as @aknarts mentioned above creating Build/PerforceBuild.txt makes UBT ignore downloading, installing, and using bundled toolchain so it picks up my system’s Clang.
If you check out this commit 97e9593070a80b408f7e87af2c277f7abf885d51 here you’ll find why this works:
# Install our bundled toolchain unless we are running a Perforce build
if [ ! -f Build/PerforceBuild.txt ]; then
echo "Installing a bundled clang toolchain"
pushd Build/BatchFiles/Linux > /dev/null
./SetupToolchain.sh
popd > /dev/null
fi
You can probably just create the Build/PerforceBuild.txt file
What linking issues are you running into when linking binaries built by clang 6 with binaries built by clang 5?
This may have other effects (like avoiding to call GitDependencies). If anything, deleting toolchain altogether (rm -rf Extras/ThirdPartyNotUE/SDKs/HostLinux/Linux_x64/) would be a better solution. However, I strongly recommend using the bundled toolchain by default since it will build a binary that can run on multiple distros, from CentOS7 and up, as opposed to using a system compiler which will generally make your binary runnable only on your distro (or closely related).
I’ve built Boost, Crypto++, libfmt, CppDB, and SQLit3 using Clang 6 and kept them in a git repository as a submodle prior to the mentioned commit for a new UE4.20 project. I have a similar setup with UE4.19 and Clang 5 on another project which works fine using the same libraries. I haven’t written any code that uses them at the moment in the new project, but I supposed Clang 5 and 6 are not ABI compatible. So, that’s why I rebuilt those libraries using Clang 6 for the new project since it’s the compiler I intend to use for this project. Are they 100% compatible?
BTW, a quick question that puzzles me. I haven’t chosen any best answer for this question yet, how did this answer end up as the best answer?
Well, I only use Linux as my primary development platform since I’m much more comfortable with it. We are not targeting Linux, but the primary development happens on Windows since I’m the only developer in the team and if necessary I do the fixes on Windows since my teammates all use Windows. It would be nice if Epic provides a way to choose another compiler over the bundled one. Thank you!
So I understand where RCL is coming from. If we ever want to have officially supported version of the Engine(or binary distribution, epic launcher etc.) there needs to be a stable toolchain behind it so all bugs and issues with it are reproducible.
But having an easy way to recompile some stuff you need using the provided toolchain and include it in the third party library location would be nice.
RCL marked the answer as the correct one as my answer was not a desired one:).
Try the binaries, they should be compatible.
Not just that, if NuLL3rr0r wants to package a game on their system and say upload it to Steam (or to give to a friend who still runs CentOS 7), they are better off using the bundled toolchain, since the version they produce with the system compiler will likely not work against Steam runtime (or on CentOS 7).
I did not actually, but AnswerHub auto-marks answers by staff as correct heh…
OK, thank you so much for the info on Steam and the bundled compiler. It makes sense. So, I’ll stick to the bundled compiler.