51–60 of 64 posts
Earlier quoted context omitted.
Well, you might know that all those source files belong to exactly one executable (or library), but how would the compiler know?
You could combine the build system (e.g. make), the linker, and the compiler into one app that knows everything and does it all in memory. It could be slightly faster but much less flexible.
Earlier quoted context omitted.
I can't say I've noticed much of a difference myself, maybe 20% faster at best.
1/5 of the way toward theoretical perfection seems pretty good.
I think you need to use a log scale for this. It's a step or two toward perfection, but perfection is infinite steps away.
Earlier quoted context omitted.
I can't say I've noticed much of a difference myself, maybe 20% faster at best.
20% sounds about right on the figures I’ve heard, but on a big build that is massive .
Also the speedup is only for Debug builds, since Release ones use LTO anyway, and no amount of linker magic makes that fast.
Earlier quoted context omitted.
20% sounds about right on the figures I’ve heard, but on a big build that is massive .
For me linking only happens once, while most of the time is actually building stuff. Also the speedup is only for Debug builds, since Release ones use LTO anyway, and no amount of linker magic makes that fast.
Earlier quoted context omitted.
wow. that borders on extortion... "you should really buy a license... who knows, otherwise your code might turn into AGPL, good luck with the expensive court fees..."
What the heck? You can get an AGPL linker for free, or pay for a non-AGPL one. This type of thing is standard in OS. Selling a product isn't extortion.
> mold stays in AGPL, but _we claim AGPL propagates to the linker's output_ [...] I don't know if this claim will hold in court, but just buying a sold license would be much easier than using mold in an AGPL-incompatible way and challenging the claim in court.
Sounds like protection money to me
It seems odd to me that we still require .o files at all. Given the final program needs to be storable in RAM + Virtual Memory it surprises me that we still need the intermediate step of pushing to the file system only to then immediately reopen and merge those files. Does someone have more info on this? Or is the reason just legacy? Or is the reason just some ideological “single responsibility” thing?
What problem are you trying to solve by keeping .o files in a processes’s memory without spilling to disk?
Note that there have been some license controversies with mold before, namely that they wanted to make all outputs AGPL, not simply mold itself [0], seems like they walked this policy back however [1]. > Open-source license: mold stays in AGPL, but _we claim AGPL propagates to the linker's output_. That is, we claim that the output from the linker is a derivative work of the linker. That's a bold claim but not entire…
Earlier quoted context omitted.
The point of copyleft is to dictate the licence you must use, if you wish to (roughly speaking) link with the copyleft-licensed work. There are plenty of libraries that you cannot use if you wish to distribute your program without making its source-code available. The unusual thing here is that the creators of a linker are apparently trying to have the copyleft licence propagate to code that is input to the linker. O…
No, the point of Copyleft is for you to not restrict the freedoms you got when you used the software when distributing it to others . You can use Copylefted software in any way to your heart's content in combination with whatever other software you want, you can just not distribute it using a more restrictive licence.
Also, your account of copyleft is still incorrect. It's true of the GPLv2 and GPLv3 licences but not true of all copyleft licences. The AGPLv3 licence, which is the one relevant here, doesn't apply only on distribution.
[0] https://www.gnu.org/licenses/copyleft.en.html
edit I think I was mistaken in putting propagate to code that is input to the linker, though. As lokar's comment points out, it's instead about the output of the linker.