[HN Gopher] mold - The (really) fast linker
___________________________________________________________________
mold - The (really) fast linker
Author : netr0ute
Score : 65 points
Date : 2023-01-14 18:58 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| yazaddaruvala wrote:
| 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?
| barbegal wrote:
| Builds can be much faster if you don't need to recompile all
| the modules into .o files.
| forrestthewoods wrote:
| What problem are you trying to solve by keeping .o files in a
| processes's memory without spilling to disk?
| satvikpendem wrote:
| 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 entirely nonsense since the linker copies
| some code from itself to the an output. Therefore, there's room
| to claim that the linker's output is a derivative work of the
| linker, and since the linker is AGPL, the license propagates. 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._
|
| Regardless of their current stance, this type of policy changes
| on a whim led me to remove mold from any of my systems, since I
| don't want all of my code in the future to automatically become
| AGPL, even by accident.
|
| [0] https://bluewhalesystems.blogspot.com/2022/11/mold-linker-
| ma...
|
| [1] https://github.com/rui314/mold#license
| lokar wrote:
| That only claims the output is AGPL, not the code you feed into
| it.
| Y_Y wrote:
| So just use mold during development and another linker for
| release.
| Beltalowda wrote:
| > 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.
| [deleted]
| dark-star wrote:
| 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..."
| CJefferson wrote:
| 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.
| daveguy wrote:
| It is unusual for the products of compilers and linkers to
| be infected by the original license. See: gcc.
| mmastrac wrote:
| I don't recall seeing a single developer tool where the
| output was anything other than fully under the copyright
| of the author of the input files (or fully liberally
| licensed in the case of additional code objects).
| Dylan16807 wrote:
| That aspect is unusual, but I don't see how that affects
| whether or not it would be license extortion.
| irogers wrote:
| Problem with my open-source startup:
| https://docs.google.com/document/d/1kiW9qmNlJ9oQZM6r5o4_N54s...
| Worth a read and I'm sure Rui would appreciate ways to resolve
| this.
| wmf wrote:
| This whole thread is old. He already split the Mac version
| into a separate commercial product.
| nicoburns wrote:
| In fairness, this was just a proposal (from someone who clearly
| has more knowledge of engineering than law). They got feedback
| that this isn't how the AGPL works, and decided to go with a
| commercial license for the macOS version instead. Which is
| annoying for me, as I was hoping to use mold on macOS and the
| monthly subscription seems a bit steep for a linker, but it
| seems like a perfectly reasonable license.
| netr0ute wrote:
| Why is the AGPL such an issue?
| [deleted]
| satvikpendem wrote:
| 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.
| kelnos wrote:
| 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.
| btdmaster wrote:
| It does not look like binutils (including ld.gold) has
| that exception[0], so I don't think the FSF would agree.
|
| [0] https://sourceware.org/git/?p=binutils-
| gdb.git;a=blob;f=READ...
| mikebenfield wrote:
| Normally the tools people use don't dictate the license they
| must use for their code.
| MaxBarraclough wrote:
| 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. Others have pointed out
| that GCC has exceptions for this kind of thing, despite
| that it is released under a strong copyleft licence
| (GPLv3+).
| the_third_wave wrote:
| 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.
| PragmaticPulp wrote:
| It's not an issue for linking AGPL code.
|
| The issue was that they wanted to claim that AGPL was
| contagious - That by using mold, your outputs would also be
| required to become AGPL.
| jeroenhd wrote:
| 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.
| ur-whale wrote:
| I'd be curious to see how fast mold can link Blender.
|
| Which would also be a good test of how good of a "drop-in
| replacement" mold is given that the Blender build process isn't
| trivial.
___________________________________________________________________
(page generated 2023-01-14 23:00 UTC)