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

Wild – A fast linker for Linux

github.com

Post reply on HN
Print view View original

141–150 of 222 posts

Re: Wild – A fast linker for Linux

#141

Post by yellowapple »

jdxcode wrote: post #119
dapperdrake wrote: post #96

Earlier quoted context omitted.

SQLite3 just concatenation everything together into one compilation unit. So, more people have been using this than probably know about it. https://sqlite.org/amalgamation.html

I totally see the point of this, but still, you have to admit this is pretty funny: > Developers sometimes experience trouble debugging the quarter-million line amalgamation source file because some debuggers are only able to handle source code line numbers less than 32,768 [...] To circumvent this limitation, the amalgamation is also available in a split form, consisting of files "sqlite3-1.c", "sqlite3-2.c", and so…

That would imply that such debuggers are storing line numbers as not just 16-bit numbers (which is probably sensible, considering that source files longer than that are uncommon), but as signed 16-bit numbers. I can't fathom a situation where line numbers would ever be negative.

Re: Wild – A fast linker for Linux

#142

Post by integricho »

pzmarzly wrote: post #19

Ever since mold relicensed from AGPL to MIT (as part of mold 2.0 release), the worldwide need for making another fast linker has been greatly reduced, so I wasn't expecting a project like this to appear. And definitely wasn't expecting it to already be 2x faster than mold in some cases. Will keep an eye on this project to see how it evolves, best of luck to the author.

what is the status of Windows support in mold? reading the github issues leads to a circular confusion, the author first planned to support it, then moved Windows support to the sold linker, but then sold got archived recently so in the end there is no Windows support or did I just misunderstand the events?

Re: Wild – A fast linker for Linux

#143

Post by berti »

leeoniya wrote: post #134
cyco130 wrote: post #130

Earlier quoted context omitted.

Not a rhetorical question: Could it be that part of the speed difference is due to the file system speed? I was shocked when I saw how much modern(ish) Windows file systems were slower than modern(ish) Linux ones.

it's usually windows defender and virus scanning that causes these massive slowdowns.

That’s exactly the problem “Dev Drive” is intended to solve I believe. I haven’t tried it myself.

https://learn.microsoft.com/en-us/windows/dev-drive/

Re: Wild – A fast linker for Linux

#144

Post by mgsloan2 »

saagarjha wrote: post #136
zelcon wrote: post #135

Earlier quoted context omitted.

Corps don't want to have to release the source code for their internal forks. They could also potentially be sued for everything they link using it because the linked binaries could be "derivative works" according to a judge who doesn't know anything.

I think you should get new lawyers if this is their understanding of how software licenses work.

See for example https://opensource.google/documentation/reference/using/agpl...

> Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

Re: Wild – A fast linker for Linux

#145

Post by o11c »

panzi wrote: post #133
pzmarzly wrote: post #19

Ever since mold relicensed from AGPL to MIT (as part of mold 2.0 release), the worldwide need for making another fast linker has been greatly reduced, so I wasn't expecting a project like this to appear. And definitely wasn't expecting it to already be 2x faster than mold in some cases. Will keep an eye on this project to see how it evolves, best of luck to the author.

Why does AGPL Vs MIT matter for a linker?

Corps want to be able to release and use tools that take away the freedoms that GPL-family licenses provide. Often this results in duplication of effort.

This is not theoretical; it happens quite frequently. For toolchains, in particular I'm aware of how Apple (not that they're unique in this) has "blah blah open source" downloads, but often they do not actually correspond with the binaries. And not just "not fully reproducible but close" but "entirely new and incompatible features".

The ARM64 saga is a notable example, which went on for at least six months (at least Sept 2013 to March 2014). XCode 5 shipped with a closed-source compiler only for all that time.

Re: Wild – A fast linker for Linux

#146

Post by jenadine »

mgsloan2 wrote: post #144
saagarjha wrote: post #136

Earlier quoted context omitted.

I think you should get new lawyers if this is their understanding of how software licenses work.

See for example https://opensource.google/documentation/reference/using/agpl... > Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

It’s their loss

Re: Wild – A fast linker for Linux

#147

Post by makapuf »

yellowapple wrote: post #141
jdxcode wrote: post #119

Earlier quoted context omitted.

I totally see the point of this, but still, you have to admit this is pretty funny: > Developers sometimes experience trouble debugging the quarter-million line amalgamation source file because some debuggers are only able to handle source code line numbers less than 32,768 [...] To circumvent this limitation, the amalgamation is also available in a split form, consisting of files "sqlite3-1.c", "sqlite3-2.c", and so…

That would imply that such debuggers are storing line numbers as not just 16-bit numbers (which is probably sensible, considering that source files longer than that are uncommon), but as signed 16-bit numbers. I can't fathom a situation where line numbers would ever be negative.

Maybe somewhere some line offset is stored as i16? (I don't understand why anyway but..)

Re: Wild – A fast linker for Linux

#148

Post by o11c »

ajb wrote: post #81

2008: Gold, a new linker, intended to be faster than Gnu LD 2015(?): Lld a drop in replacement linker, at least 2x as fast as Gold 2021: mold, a new linker, several times faster than lld 2025: wild, a new linker...

Rarely mentioned: all of these occur at the cost of not implementing a very large number of useful features used by real-world programs.

Re: Wild – A fast linker for Linux

#149

Post by usefulcat »

yellowapple wrote: post #141
jdxcode wrote: post #119

Earlier quoted context omitted.

I totally see the point of this, but still, you have to admit this is pretty funny: > Developers sometimes experience trouble debugging the quarter-million line amalgamation source file because some debuggers are only able to handle source code line numbers less than 32,768 [...] To circumvent this limitation, the amalgamation is also available in a split form, consisting of files "sqlite3-1.c", "sqlite3-2.c", and so…

That would imply that such debuggers are storing line numbers as not just 16-bit numbers (which is probably sensible, considering that source files longer than that are uncommon), but as signed 16-bit numbers. I can't fathom a situation where line numbers would ever be negative.

Cue C or C++ should-I-prefer-signed-or-unsigned-integers debate

Re: Wild – A fast linker for Linux

#150

Post by o11c »

sylware wrote: post #109
bmacho wrote: post #71

Earlier quoted context omitted.

What do you mean by this?

ELF(COFF) should now be only an assembler output format on modern large hardware architecture. On modern large hardware architecture, for executable files/dynamic libraries, ELF(PE[+]) has overkill complexity. I am personnally using a executable file format of my own I do wrap into an "ELF capsule" on linux kernel. With position independent code, you kind of only need memory mapped segments (which dynamic libraries a…

You're giving up a lot if you stop using a format that supports multiple mapping, relro, dynamic relocations, ...
Post reply on HN