Update to Linux 5.12.9 and add missing packages on Archlinux/Manjaro...

[bensuperpc]

Update to Linux 5.12.9 and add missing packages on Archlinux/Manjaro on readme

Signed-off-by: Bensuperpc [email protected]

[nathanchance]

Thanks for the pull request!

Is there any real reason to upgrade to Linux 5.12.9? I do not typically upgrade from the first stable release unless there is a build fix because it creates unnecessary churn. In other words, your profiling data is not going to really change from 5.12 to 5.12.9. If the build is broken for you without the upgrade then sure.

What build error did you see due to lack of cpio and zlib? zlib should be pulled in via base-devel because binutils depends on it so that is not necessary to add. Please keep the list sorted.

[bensuperpc]

Thanks for the pull request!

Is there any real reason to upgrade to Linux 5.12.9? I do not typically upgrade from the first stable release unless there is a build fix because it creates unnecessary churn. In other words, your profiling data is not going to really change from 5.12 to 5.12.9. If the build is broken for you without the upgrade then sure.

What build error did you see due to lack of cpio and zlib? zlib should be pulled in via base-devel because binutils depends on it so that is not necessary to add. Please keep the list sorted.

I usually keep the linux kernel as up to date as possible with the latest patches
You are right for zlib, for cpio, when building llvm + clang with PGO this package was missing,

I tested with this command:
python3 build-llvm.py --assertions --branch "release/12.x" --shallow-clone --projects "clang;libcxx;libcxxabi;compiler-rt;lld;lldb;clang-tools-extra;openmp;parallel-libs;libclc;libunwind;polly;pstl" --targets X86 --lto=thin --build-type=Release --pgo kernel-allyesconfig

Sorry for my English, I'm French ^^

[nathanchance]

I usually keep the linux kernel as up to date as possible with the latest patches

Definitely a good practice. In this particular case, there is not really much of a point. The stable releases only include bug fixes, which are almost always only seen at run time. Given that we are not running these kernels, only building them, I do not think it is worth upgrading it but I do not have a strong opinion.

You are right for zlib, for cpio, when building llvm + clang with PGO this package was missing,

Thanks for the command, I will take a look. The addition of cpio is obviously fine, please just keep it alphabetized in the list of packages.

I tested with this command:

python3 build-llvm.py --assertions --branch "release/12.x" --shallow-clone --projects "clang;libcxx;libcxxabi;compiler-rt;lld;lldb;clang-tools-extra;openmp;parallel-libs;libclc;libunwind;polly;pstl" --targets X86 --lto=thin --build-type=Release --pgo kernel-allyesconfig

Just a few comments:

1. --build-type defaults to Release so you can drop it.

2. If you are purely concerned with building the kernel, you will drastically speed up your LLVM build times if you drop libclc, libcxx, libcxxapi, libunwind, lldb, openmp, parallel-libs, and pstl, as the kernel does not use any of this. If you want to use this toolchain system wide, you would be better using the LLVM PGO benchmark: --pgo.

Sorry for my English, I'm French ^^

Your English is perfectly fine :)

[bensuperpc]

I tested with this command:
python3 build-llvm.py --assertions --branch "release/12.x" --shallow-clone --projects "clang;libcxx;libcxxabi;compiler-rt;lld;lldb;clang-tools-extra;openmp;parallel-libs;libclc;libunwind;polly;pstl" --targets X86 --lto=thin --build-type=Release --pgo kernel-allyesconfig

Just a few comments:

1. --build-type defaults to Release so you can drop it.

I would like to make a docker container with the compiler, some arguments are currently unnecessary, but they will be editable when building the docker image

2. If you are purely concerned with building the kernel, you will drastically speed up your LLVM build times if you drop libclc, libcxx, libcxxapi, libunwind, lldb, openmp, parallel-libs, and pstl, as the kernel does not use any of this. If you want to use this toolchain system wide, you would be better using the LLVM PGO benchmark: --pgo.

I will change "kernel-allyesconfig" to "llvm, thank you for the advice

do you know how to make a static toolchain, which can be used on most linux distributions without the dependencies (or as little as possible), the "-static" flag is made for that, but is it with LLVM + clang is there a better way ?
I realized this, I built the toolchain under Archlinux, but it did not work under debian (in docker image) because of missing shared libraries or different versions

Sorry for my English, I'm French ^^

Your English is perfectly fine :)

Thank you ^^

[msfjarvis]

do you know how to make a static toolchain, which can be used on most linux distributions without the dependencies (or as little as possible), the "-static" flag is made for that, but is it with LLVM + clang is there a better way ?
I realized this, I built the toolchain under Archlinux, but it did not work under debian (in docker image) because of missing shared libraries or different versions

It is currently not possible to create a static build of Clang, and we are tracking this as #150.

[nathanchance]

do you know how to make a static toolchain, which can be used on most linux distributions without the dependencies (or as little as possible), the "-static" flag is made for that, but is it with LLVM + clang is there a better way ?
I realized this, I built the toolchain under Archlinux, but it did not work under debian (in docker image) because of missing shared libraries or different versions

As Harsh pointed out, we are tracking this already. glibc is very hard to statically link against so we would need to use something like musl, which LLVM has some minor issues being linked against (although Alpine Linux does it so it should not be too hard). However, if you are building this toolchain in a Docker container, why not just require that the toolchain also be run in that same container?

[nathanchance]

@bensuperpc I opened #160 and #161 with full attribution to you on the commits that you did because I noticed a few other things that needed to be fixed. Please take a look!

For the record, I do not think that the uprev to Linux 5.12.9 is necessary but you did the work already so it does not hurt.

Cheers!

[bensuperpc]

Thank you for your answers.
Ok ^^