Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mold – A really fast linker

github.com

Post reply on HN
Print view View original

21–30 of 64 posts

Re: Mold – A really fast linker

#21

Post by the_third_wave »

MaxBarraclough wrote: post #20
mikebenfield wrote: post #8

Earlier quoted context omitted.

Normally the tools people use don’t dictate the license they must use for their code.

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.

Re: Mold – A really fast linker

#23

Post by Dylan16807 »

daveguy wrote: post #15
CJefferson wrote: post #13

Earlier quoted context omitted.

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.

It is unusual for the products of compilers and linkers to be infected by the original license. See: gcc.

That aspect is unusual, but I don't see how that affects whether or not it would be license extortion.

Re: Mold – A really fast linker

#24

Post by jeroenhd »

netr0ute wrote: post #3
satvikpendem wrote: post #2

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…

Why is the AGPL such an issue?

It depends if you find it acceptable that the work you created gets assigned the AGPL license. However, this problem was already solved at this point, so it's a non-issue these days.

One practical problem, even for developers who are fine with licensing their code to whatever open source license is easiest, is that not all open source licenses are AGPL compatible. Take for example the Mozilla Public License, which is inherently incompatible with AGPL because of the terms imposed; this means that any project using MPL licensed libraries could no longer be linked with Mold.

License incompatibilities can be a huge pain (see: ZFS + Linux). If you develop software for yourself this isn't a problem, but if you intend to distribute your software this becomes more of an issue.

This is probably also the main reason why normal linkers/compilers don't impose licenses on the produced work.

Re: Mold – A really fast linker

#25

Post by yazaddaruvala »

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?

Re: Mold – A really fast linker

#26

Post by Beltalowda »

satvikpendem wrote: post #2

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…

> this type of policy changes on a whim

Ehh...

"I want to share another idea in this post to keep it open-source [..] Let me know what you guys think" is not a "policy change on a whim". It's an idea. It was not "walked back" on, because it was ... just an idea.

Your comment is a horrible misrepresentation of what's actually in the post.

Re: Mold – A really fast linker

#27

Post by barbegal »

yazaddaruvala wrote: post #25

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?

Builds can be much faster if you don't need to recompile all the modules into .o files.

Re: Mold – A really fast linker

#28

Post by forrestthewoods »

yazaddaruvala wrote: post #25

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?

Re: Mold – A really fast linker

#29

Post by jchw »

yazaddaruvala wrote: post #25

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?

At the highest level of performance needs, if you want to parallelize the build across machines, you're going to need some kind of storage abstraction for intermediate files since translation units are the easiest place to split builds at.

In some places, where builds are particularly optimized, there are special distributed filesystems just for object files. In this case, it's not necessarily true that the object files are backed by disk even.

Being backed by disk locally mainly helps for incrementally building so that you can change one file and only recompile intermediate files for translation units that depend on this file. Disk/FS caching presumably helps a lot with redundant I/O, and I think most of the benefit of building with tmpfs winds up being putting the source itself in RAM.

Edit: also it's worth noting that many compilers can output object files which can be linked by other linkers, allowing you to mix output from different compilers in some circumstances.

Re: Mold – A really fast linker

#30

Post by adament »

kelnos wrote: post #12
satvikpendem wrote: post #5

Earlier quoted context omitted.

It's not, if it's contained to just the linker itself (which it is now), that's not why I stopped using it. I did so because it seems like they don't understand that much about AGPL and licensing in general and could change their license terms at any point to say something like "we claim AGPL propagates to the linker's output" which is very legally tenuous itself to claim so.

Tenuous or not, I believe GCC explicitly has a licensing exception that states that compiler output is not considered a derivative work of the compiler, and thus must also be licensed under the GPL. So the GNU/FSF folks at least thought it was a concerning enough legal idea to explicitly account for it. Not sure we can say that a linker is the same as a compiler in this sense, but if so, maybe it is indeed worrisome.

If I recall correctly it is the standard libraries(such as libstdc++) that need this exception and not the compiler itself.
Post reply on HN