I agree it isn't optimal. But, Apple is asking all their downstream library authors to migrate to a new platform and support the old one (via "universal binaries").

It just isn't feasible or practical for app developers nor for the library authors, especially when those authors are providing free and open source libraries.

I wouldn't have imagined it possible, but we are shipping a x86 binary that uses a lot of open source libraries, that do video compression and decompression. And, Rosetta is incredible and the performance is amazing despite it all being x86.

The M1 is a feat of engineering and Rosetta is an incredible and unexpected part of that marvel.

It's not feasible or practical for them to recompile their code?

I can't compile my code until a downstream library compiles their code. They can't compile their code until a downstream library, they depend on, compiles their code. It all has to happen before any of it can happen. It eventually will, but we'll have to be patient, as is always the case with global changes.

Sometimes you can just raise a PR and provide an arm build. I did this recently with a lisp library I use.

If the library is open source, you can be the person who does that :)

Or you could feed your kids. A small team can not maintain that much and if it is not your core business you should probably not try.

How is a library you depend on not your core business? If they don't support things you want, then this sounds like your problem.

The SSL library is nobody's core business, yet every business depends on it. Most libraries are just infrastructure, way down, that we build stuff on. Core business has a specific meaning:

> the business activity that is main source of a company's profits and success

Maintaining libraries is not the core business of those that use those libraries, most of the time. That's why people use libraries.

This is it an either/or: you can find the problem libraries and submit the work back upstream so you don’t have to maintain it. Then, for the upstream that don’t cooperate, fork temporarily until you find an alternative.

To their point, all of this is not trivial. You could just compile as x86 and be done with in in 5 minutes, assuming the performance hit is acceptable.

It’s not trivial, but it’s also not a long-term maintenance cost if upstream accepts the patch.

> long-term maintenance cost if upstream accepts the patch

When they said "maintain", I read it as short term, doing this if and when for all libraries down the dependency chain. Or, compile as x86, and wait until external resources push for the support.

As the article shows, it’s not as simple as changing a command-line option.

This seems to be an artifact of using Qt Creator. Generally speaking it is just a matter of running the same compilation steps with different targets (so long as you don't have arch-specific stuff in there like reliance on aliasing behavior or specialized simd, of course). Qt uses just about the most complicated build process I've seen outside of Xcode/objective-c++.

I'm curious to compare what the GTK build process looks like as a universal binary; I think RawTherapee has done it.

I meant "alignment" there not "aliasing" but the point is the same.

Well, yeah. That has been the trade-off forever. You get whatever is reasonably easy to make.

Over all users seem to prefer something over nothing when it comes to software.

This isn't the quality standard I have, but a lot of devs do and I find it pretty understandable considering the required trade-offs.

Give me a GitHub action template that builds universal Qt binaries for Mac given an existing cmake-based build workflow and I'll consider it. Until then, it was already enough work piecing things together for a regular Intel app-bundle because every howto you'd find does things differently and none of them are a perfect match to your setup. Even windows was easy compared to that...

Watch me act all surprised when the transition is complete and Apple stops supporting Rosetta 2! They only did it once before with Rosetta 1!