Apple Releases New Static Linker
twitter.com
twitter.com
https://twitter.com/nabbisen/status/1665936938837344256
> I installed Xcode 15 Beta to try out the new Apple's linker. It seems that my mold/sold linker is still a bit faster than theirs, but the gap has now reduced to ~60% when linking the sold linker itself on my Mac Studio. Apple's new linker is in the same league as mine. Great job!
I think this "Apple's new linker is in the same league as mine. Great job!" response is full of tact and grace, considering Apple just undercut his business.
I dont think he was willing to sell to Apple for what Apple would consider as reasonable price anyway.
Large companies (Apple, Amazon, and the like) would likely buy the company rather than license their product (see Dark Sky (now WeatherKit), Kiva (now Amazon Robotics - https://www.fromscratchradio.org/show/mick-mountz 23:22 )) so that they can't lose control over something that they want when management for one of there tools changes.
And so why use mold (license problems and they wouldn't want to impose the AGPL on all their developers), or be a reseller of sold ($8/month/user - how many developers are in the Apple developer program) - it comes down to "it is better for us to develop our own and release it so that there is certainty about the license for any developers who use it."
It would even be further beyond the pale to say "here is a linker for 3rd party developers to use... oh, and its AGPL, sorry 'bout that."
So to the question from the GP:
> Why didn't Apple just use mold?
Because they won't tell 3rd party developers to use AGPl software or require a 3rd party developer to use a different 3rd party developer's licensed software that may change.
If Apple is going to release something, they're going to develop it and release it themselves with as few other encumbrances as possible.
I remember an SFC blog post[2] expressing distaste for such scare-tactics applications of copyleft on the part of MySQL AB in the early 2000s. (As opposed to the initial goal of copyleft, that is using a legal hack to eventually force most software to become free/libre.) This case is maybe less unpleasant, but only marginally so, I think.
[1] https://gist.github.com/lleyton/9c0b75d065f37333ea9851b6cad1..., discussed today at https://news.ycombinator.com/item?id=36225016
[2] https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
Now, thinking about that case, I guess that Apple could make it easy for people to depend on AGPL software that they download on their own, and that Apple only provides some sort of index or crawlers for it. No need for Apple to have AGPL software on their end.
No shame on the book, it is a classic, but it is certainly a bit long in the tooth.
I am very interested in linkers, but find them a bit inaccessible to learn about.
Gold blog posts:
https://www.airs.com/blog/archives/38 and https://en.wikipedia.org/wiki/Gold_(linker)
Design and implementation of Mold:
Also at install time the application would run all its initialization steps including GUI object allocation, with GUI object handles permanently assigned in their own segment of a global address space. The linked and initialized state of the application would be stored. Then launching the application would be more similar to a resume-from-suspend operation: memmap the pre-initialized state into its already reserved segment of address space and reactive the frozen gui objects.
Probably I'm naive: I've never built any of this kind of low-level OS stuff. But I really do think there is room to re-envision some things which were decided in the 1970's based on constraints of 1970's hardware.
We’ve been moving away from this for security reasons with ASLR and position independent executables.
Fixed targets are dangerous for security reasons.
And, how do you run multiple programs out of the same binary?
Re: ASLR, yeah I think you would lose most of that mitigation. Would it be worth it to make launching even the biggest programs instantaneous? The usability upside could be something amazing; maybe some other security mitigations could take the place of ASLR.
For individual applications there are many reasons that isn't reasonable (performance, security, etc).
But the perf gains you're asking for are mostly supported by the shared cache. The vast majority of launch time for an application is not the dynamic linker. It's the actual "load from disk" for the text and resources, then a pile of init logic.
Now plenty of apps have unnecessarily large start up times, but those apps can largely be improved without just doing more work at install time - it's simply that a lot of devs don't care. There's a lot of "if it's not being measured, it's not being improved" for launch time for many - most? - projects and companies that means launch time is just slow for no reason.
That is exactly what I want to do. Imagine your system had the full 64 bit address space populated with RAM. You launch every installed application simultaneously and let them run thru init to the point where they are ready for user interaction. Then suspend the whole system to disk. Thats what I want the "applications installed" state to look like.
In actual use you have limited RAM and launch applications one at a time. At launch time it is un-suspending the already initialized application. It has its own reserved virtual memory addresses so no need to reallocate new memory and no conflict with other running applications.
Emacs used to do something like this (maybe still does?) but in a very hacky way. I'd like it to be how the whole OS works.
ld64 is a fork of the old and slow GCC ld linker. It has accumulated a thousand switches and features and hacks over the years. The move to only dynamic linking meant that most of them can never be used again. So now is a great good time to do a complete rewrite, especially with lld and mold as models; both were architected by the awesome Rui Ueyama. Throw away all the crap, parallelize everything and yeah, it should be fast.
ld64 was a complete rewrite, circa 2005, courtesy of Nick Kledzik. `opensource.apple.com` has still the old Changelog(s). https://github.com/rotten-apples/ld64/blob/master/ChangeLog
What architectures would it support? I assume it handles aarch64. It may already handle x86-64. macOS and iOS don't run on any others. I doubt Apple would be interested in making it support other OSs that run on more architectures.
(It's probably a faux pax of me to say this, but I wonder if the parent comment was written by a LLM...)
How on Earth would you know, much less prove, text originated from LLM?
Your comments come across as meaningless if you're on a mission to disrespect commentors frivolously.
That's pretty disrespectful, I expect an apology from you
> I doubt Apple would be interested in making it support other OSs that run on more architectures
I don't think Apple is only using ARM and their chip for their whole stack, in fact, their servers run something else, and they support software that runs on other OSes wich run plenty of different architectures, including X86_64, and they are exploring a plethora of architectures [1]
> I assume it handles
> It may already handle
"Faux pas" indeed, let's stop assuming and let's stay positive, nice and respectful to each other
[1] - https://www.techpowerup.com/298936/report-apple-to-move-a-pa...
> I don't think Apple is only using ARM and their chip for their whole stack, in fact, their servers run something else, and they support software that runs on other OSes wich run plenty of different architectures, including X86_64, and they are exploring a plethora of architectures [1]
Now I understand why you suggested it might run on other architectures / OSs. I'm skeptical though. They may develop/run software on Linux/Windows, but I haven't seen any examples of them releasing a development toolchain (e.g. any part of Xcode) for those OSs (with the obvious exception of platform-independent LLVM improvements). Likewise microprocessor-level stuff (afaict everything they do with risc-v).