CRUX

Welcome to CRUX bug tracking.
Tasklist

FS#1818 - clang/llvm: use dynamic linking

Attached to Project: CRUX
Opened by Steffen Nurpmeso (steffen) - Friday, 03 July 2020, 18:44 GMT
Last edited by Tim Biermann (tb) - Monday, 06 July 2020, 17:58 GMT
Task Type Improvement
Category ports → core/opt
Status Closed
Assigned To Thomas Penteker (teK)
Operating System CRUX
Severity High
Priority High
Reported Version 3.5
Due in Version 3.6
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

clang builds upon the llvm code base, but until now builds its own copy of llvm, which takes a lot of time and disk space.
TimB in his private repo as well as ArchLinux use dynamic linking, thus massively decreasing the mentioned.

Personally i use Tim's recipe, which introduces a compiler-rt package (https://compiler-rt.llvm.org/) as the missing link (i.e., llmv, <- compiler-rt, <- clang).

Thanks.
This task depends upon

Closed by  Tim Biermann (tb)
Monday, 06 July 2020, 17:58 GMT
Reason for closing:  Implemented
Additional comments about closing:  partly implemented in 3.6
Comment by Juergen Daubert (jue) - Friday, 03 July 2020, 19:25 GMT
FTR, arch uses the same flags, which are relevant here, as the CRUX port opt/llvm does:

arch: -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON
crux: -DLLVM_BUILD_LLVM_DYLIB=1 -DLLVM_LINK_LLVM_DYLIB=1
Comment by Steffen Nurpmeso (steffen) - Friday, 03 July 2020, 21:23 GMT
Well ok. But Tim uses that compiler-rt intermediate thing, and the resulting binaries are *much* smaller, and the compile time is reduced a lot.
I do not know how to CC: Tim here, i will ask him on IRC the next time he shows up and i am there, he should post the three recipes, then you will see the difference.
Comment by Tim Biermann (tb) - Saturday, 04 July 2020, 00:04 GMT
compiler-rt has nothing to do with DYLIB or SHARED_LIBS. compiler-rt is always recommended as complementary for clang, and i just found out that chromium demands compiler-rt links for clang to be compiled nowadays. otoh, firefox, as a prominent clang user, doesn't need compiler-rt. but since that's actually encouraged by upstream, i created that port for myself as well.

not using DYLIB is actually discouraged, but i have no idea why. i just tried it because i am curious fella, and it just works, so i stuck to it.

the biggest speed advantage comes from not building llvm twice, really. i'll attach the clang port i use. i have not hit any problem with it. I started to build all the ports from the llvm family or relatives (e.g. mesa) with clang (hence my check) as well as the kernel itself (make LLVM=1 CC=clang) - no problems at all.
Comment by Danny Rawlins (Romster) - Saturday, 04 July 2020, 09:09 GMT
I two am using tim's ports and I have commit access and I also added llvm-32, I have not hit a problem either and it's made contrib/firefox load considerably faster. But alas it's not recommend upstream and we follow upstream.
Comment by Tim Biermann (tb) - Saturday, 04 July 2020, 13:01 GMT
I might add: same stuff doesn't work as well on armv7l (aka, pi4 for me currently), so that i switched back to DYLIB=ON
Comment by Steffen Nurpmeso (steffen) - Saturday, 04 July 2020, 21:57 GMT
But isn't this just a configure/build mess problem upstream?
Before i gained access to Tim's Pkgfiles i tried to do dynamic linking on my own, and followed upstream documentation, but it did not work out.

I do not know, what is actually meant with DYLIB=on. Can't you just set this in addition /to BUILD_SHARED_LIBS it then has to be) and still gain the good effects?
Or do i need to reread the thing that is linked from the page that Pedja referred to :)
Comment by Tim Biermann (tb) - Sunday, 05 July 2020, 08:46 GMT
>But isn't this just a configure/build mess problem upstream?
Kind of. The documentation basically always just starts with 0 and then pulls llvm+${subproject}, the way that opt/clang does. It seems very unneeded though.

>I do not know, what is actually meant with DYLIB=on.
DYLIB bundles all libs to one big one. https://releases.llvm.org/10.0.0/docs/CMake.html#llvm-specific-variables

>Can't you just set this in addition /to BUILD_SHARED_LIBS it then has to be) and still gain the good effects?
I don't believe so.

>Or do i need to reread the thing that is linked from the page that Pedja referred to :)
I wasn't able to extract information that I didn't have before that from there.
Comment by Tim Biermann (tb) - Sunday, 05 July 2020, 08:54 GMT
https://releases.llvm.org/10.0.0/docs/BuildingADistribution.html

Also this one contains a warning on shared libs topic O:)

Loading...