Exact commands to replicate Clang 3.9.1 binary compilation release

I need to recompile an older version of Clang (3.9.1) for compatibility with an older software product (UE4.14.3) on a newer system (UB20.04, without libm *_finite library support; see ⚙ D74712 Remove *_finite library support, following upstream).

The binary 3.9.1 provided by LLVM Download Page works except for the fact it assumes *_finite library support;

https://releases.llvm.org/3.9.1/clang+llvm-3.9.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz

LLVM Download Page contains a large number of binaries, but no documentation regarding their exact compilation. What was the exact procedure (set of commands/script) used to generate their contents? I wish to replicate their generation after applying the relevant Clang source patch.

I don’t have an answer for your question, but recently I had to rebuild all the Clangs in order to enable assertions, and do it in a period-correct fashion to make sure old crashed still reproduce. I guess that release builds were done with a similar process. I posted details here (scroll to the right to see CMake invocation line)

Which platform do you need it for? Most Unix based systems use the script llvm/utils/release/test-release.sh

But 3.9 is so old that the script might not have been around back then.

1 Like

https://github.com/llvm/llvm-project/blob/llvmorg-3.9.1/llvm/utils/release/test-release.sh exists, and I think I can remember building with it. But the script might assume old python, old host operating system properties, etc. So it will probably be best to try it in a container with, say, Ubuntu 16 in it… :slight_smile:

1 Like

The origin of that specific binary can be traced to this thread: [cfe-dev] 3.9.1 -final has been tagged

As Tobias mentioned, it was built with the test-release.sh script.

That script goes way back. For 3.9.1 it would have even been the “modern” version which uses cmake instead of autoconf :slight_smile:

1 Like

Thank you very much for your quick support, this has greatly assisted my workflow.

I used the following commands to patch, compile, and install the Clang 3.9.1 release binaries on Ubuntu 20.04;

Patch:
To resolve the compilation error lambda parameter CGF previously declared as a capture:

  • nedit /USERFOLDER/llvm-3.9.1.src/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp
  • replace all lambda parameters that have same name as captured variable; CGFCGF2;
&NumOfPtrs](CodeGenFunction &CGF2, PrePostActionTy &) {
&NumOfPtrs](CodeGenFunction &CGF2, PrePostActionTy &) {
auto &&ThenGen = [&D, &CGF, Device](CodeGenFunction &CGF2, PrePostActionTy &) {

Dependencies (minimal):

sudo apt-get install libtinfo5
sudo apt-get install chrpath

Compilation:
https://releases.llvm.org/download.html

download and extract cfe-3.9.1.src.tar.xz
download and extract llvm-3.9.1.src.tar.xz
mv cfe-3.9.1.src clang 
mv clang /USERFOLDER/llvm-3.9.1.src/tools
cd /USERFOLDER/llvm-3.9.1.src/utils/release/
mkdir final
ln -s /USERFOLDER/llvm-3.9.1.src final/llvm.src
./test-release.sh -release 3.9.1 -final -no-compare-files -test-asserts -triple x86_64-linux-gnu-ubuntu-16.04 -no-checkout

Installation:

extract final/clang+llvm-3.9.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz
cd clang+llvm-3.9.1-x86_64-linux-gnu-ubuntu-16.04
sudo cp -r * /usr/local/
sudo ln -s /usr/local/bin/clang++ /usr/local/bin/clang++-3.9 [optional]

Testing:
I tested the compiled clang++-3.9 in my environment and it works fine. I performed a number of successful compilations using various parameter combinations but could not replicate the exact output of [cfe-dev] 3.9.1 -final has been tagged;

Expected Passes    : 26436
Expected Failures  : 139
Unsupported Tests  : 424

Addendum:

For reference, I am yet to resolve the original libm obsolete *_finite function support issue as the functions are referenced in a UE4.14.3 precompiled third party PhysX library (compilation script not readily available). It appears however that they can be compiled without the -ffast-math flag (e.g. UE4.17+) which should theoretically resolve the issue.

It’s been too long to actually recall, but I don’t recall doing anything odd, and it’s unlikely I modified the script.