[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: linking with mold
From: |
Andreas Fink |
Subject: |
Re: linking with mold |
Date: |
Thu, 23 Dec 2021 13:24:31 +0100 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.53 |
H. Nikolaus Schaller wrote on 23.12.21 09:33:
>
>> Am 22.12.2021 um 12:57 schrieb Andreas Fink <afink@list.fink.org>:
>>
>> I'm happy in terms of functionality with gold linker but linking my
>> projects is quite slow. My projects has around five thousands source
>> files. All very small but still lots of them. So linking is taking most
>> of the time when I modify and run something.
> Hm.
>
> Couldn't you group those 5000 files into a hierarchy of libraries/frameworks?
They are already. But I have two big libraries. ulibgsmmap (1046 .m
files) and ulibdiameter (654 .m files).
They can't be split further because underlying protocol standards they
implement.
> And re-link only a small modified portion of the full dependency tree?
to build the final binary it still has to link everything together.
Either at build time or at start time by the dynamic linker.
> Current Linux kernel has ca. 32911 .c files but links (not compiles) within
> seconds by such a hierarchy if I change a single source file.
Linux kernel is pure C and is mostly modules which are not recompiled if
you change a single source file
I'm not complaining about my current setup. I just think it could be
improved.
So far a full rebuilt on a Debian 10 vm on a 28 core MacPro takes 6
minutes. (on a M1 mac it takes 5minutes 40 sec). Most of the time I
don't need a full rebuilt but I can see the linking part taking a lot of
time. Having the option to use a linker which runs on many cores could
drastically improve that.
using "mold" would thus nice. But I wanted to be sure i don't run into
any issues like with ld or lld. Hence my question if anyone tried.
If not, I will investigate and test myself.