MacOSX-SDKs VS mold

We are making really good progress and will have a prototype in the next month or so. See the Github issues for Linux[1] and Windows[2]

[0] https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10...

[1] https://github.com/withfig/fig/issues/34

[2] https://github.com/withfig/fig/issues/35

Ah, really? :/ I was only trying to help as I’ve needed some in the past and the repos I’ve found before have been up for years (eg https://github.com/phracker/MacOSX-SDKs) with no apparent issues, but may not have had the latest SDKs. I assume if Apple had an issue they’d contact me? Of course I’d remove it immediately if asked.

Another approach for this is to explore the format through Apple's tools for building dictionaries – as they still provide a "Dictionary Development Kit" in Xcode's downloadable "Additional Tools" package (which has documentation for the XML format).

It turns out that dictionary bundles are entirely supported by system APIs in CoreServices! The APIs are private, but Apple accidentally shipped a header file with documentation for them in the 10.7 SDK [1].

[1] https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10...

You still need the target SDK extracted from XCode: https://github.com/phracker/MacOSX-SDKs

I assume this submission is trying to highlight the specific message (2023-01-24) : https://github.com/rui314/mold/issues/190#issuecomment-14028...

Fyi... the author wrote a more expansive blog post about selling dev tools a few months later (2023-06-06) and there was a related HN thread about it: https://news.ycombinator.com/item?id=36225016

It looks like HN automatically stripped the comment I originally linked to: https://github.com/rui314/mold/issues/190#issuecomment-14028.... The title should be more clear in this context.

I'm amazed at how quickly the author responds to requests: https://github.com/rui314/mold/issues/1057

From the report to the fix in less than two days.

I'm not sure how competitive it will be with lld, especially if we consider ThinLTO (which takes multiple minutes on 64-core machine) - it can make the advantages of mold insignificant.

> it wasn't worth the hassle

Did the authors say that? According to their changelog [1] they stated "we've been attempting to monetize our product...this approach didn't meet our expectations...we don't want to persist with a strategy that didn't work well" which I infer to mean they didn't sell enough licenses.

Even if selling licenses is a hassle, then that indicates a problem with the open source ecosystem as GitHub and other code hosting websites should offer monetization tools for selling closed-source licenses directly from their web interface. I'm talking legal forms, templates, payment processors, and product tracking. Selling licenses should be easy, not a hassle.

[1] https://github.com/rui314/mold/releases/tag/v2.0.0

> Mold did it first, though: https://github.com/rui314/mold

Before LLD?

The problem is not Apple-specific and actually can (and perhaps will) be spread elsewhere

The specific optimization this achieves is during build time only: these new files are primarily quicker to link static libraries. It is a small shift of some of the linking pipeline into the (parallel) builds of dependencies, rather than heaping it all onto the linker at the end of the build, having to essentially re-link from scratch for every small change

Parallelization has long been known as the best way to speed up linking. This change comes in addition to a rewritten parallel linker. Mold did it first: https://github.com/rui314/mold

This is one of the largest improvements that Zig brings – lightning fast recompiles, bringing the native development cycle closer to web speed.

Static linking is required to get the best performance: with cross-language PGO, LTO and dead code elimination

If this optimization is generally applicable and developers find it worthwhile, I could imagine this making its way to GCC land

I've read good things about https://github.com/rui314/mold , at least on development. YMMV.