Other Getting Catalina to play nice with 32-bit binaries and applications

[B S Magnet]

Arising from a discussion aside to come up on another thread, @TheShortTimer suggested this question be spun off into a new thread.

Even as Apple formally withdrew support for running 32-bit applications from Catalina forward, the ability to use 32-bit binaries in Catalina persisted with the inclusion of an nvram boot-args setting, as mentioned by @Dayo earlier in the same thread. Indeed, this discovery, originally reported by the Hackintosh community’s netkas, has been known since 2019.

There are selected dynamic libraries which would need to be sourced from, optimally, the final version of Mojave, to help facilitate the running of 32-bit binaries, but the key word here is binaries — not the usual clicking of an “Application.app”, et voilà, 32-bit applications play nice on Catalina. Which libraries those are is less clear, as the only suggestion is to link the entire dyld directory location from Mojave to Catalina. There hasn’t, so far, been a more selective means of managing this — to pick only those libraries needed and nothing more.

There may, however, be a way to make this happen. That’s what this topic hopes to invite.

What that thread (nor any source we’ve been able to find so far) was unable to answer is which libraries and/or frameworks, sourced from Mojave, may permit the running of 32-bit applications in Catalina? Assembling that list of needed libraries — to pull only those libraries needed — is what this thread can discuss.

This legacy capability may be valuable for users of specialized software which either was never ported to 64-bit or is tied to external hardware for which their ongoing utility is still handy, but software support for them is frozen in the time the product was current. A couple of good examples include utilities for legacy MIDI devices and dedicated film scanners.

(I post this with self-awareness this task may not actually be possible.)

Anyhow, if healthy participation warrants it, I can convert this to a wikipost. Cheers.

 

[Wowfunhappy]

as the only suggestion is to link the entire dyld directory location from Mojave to Catalina.

The reason this is the only suggestion, I'm pretty sure, is that you really do need basically all of them! The core system libraries are highly dependent on each other. And a 32 bit binary is unable to load a 64 bit library.

If you want to see which libraries specifically are needed, that's relatively easy. Try launching a 32bit app (on a compatible OS like Mojave) with the DYLD_PRINT_LIBRARIES environment variable set to 1. For example:

DYLD_PRINT_LIBRARIES=1 /Applications/iWork\ \'09/Pages.app/contents/MacOS/pages

You're going to see that it loads a LOT of libraries! You would need to take all of these from Mojave, because none of the libraries that ship with Catalina have 32 bit slices, which means none of them can be used by a 32 bit app!

 

[B S Magnet]

The reason this is the only suggestion, I'm pretty sure, is that you really do need basically all of them! The core system libraries are highly dependent on each other. And a 32 bit binary is unable to load a 64 bit library.

If you want to see which libraries specifically are needed, that's relatively easy. Try launching a 32bit app (on a compatible OS like Mojave) with the `DYLD_PRINT_LIBRARIES` environment variable set to `1`. For example:

DYLD_PRINT_LIBRARIES=1 /Applications/iWork\ \'09/Pages.app

You're going to see that it loads a LOT of libraries! You would need to take all of these from Mojave, because none of the libraries that ship with Catalina have 32bit slices!

OK. Fair point (and yes, I was aware the dyld list is exhaustive).

That said, is there a reason behind linking to those libraries in lieu of copying them in to (a final updated version of) Catalina as a permanent part of that environment?

This project is akin to getting Snow Leopard working on PowerPC. That is of course a thing people have done

I would love to meet those people…

Also, in defence of that project’s endeavour, there wasn’t a boot-args variable to enable a more complete (or robust) degree of support for PowerPC functionality within the developer builds of Snow Leopard. That alone, with respect to Catalina, indicates there was a reason internal developers at Apple kept that flag around beyond the official sunsetting of 32-bit application access.

but in that case, the community tracked down a developer beta of Snow Leopard with native PPC support, and from there it was just a matter of filling in the gaps. You'd need something like that for Catalina.

In short, 32-bit binaries may work, and some need to be aided by Mojave-sourced dylds. But this is to say there was even more, beyond libraries, which got pulled from Catalina. In short: is this a valid summary?

 

[TheShortTimer]

I would love to meet those people…

A very modest response from you. @B S Magnet

 

[Wowfunhappy]

That said, is there a reason behind linking to those libraries in lieu of copying them in to (a final updated version of) Catalina as a permanent part of that environment?

Because it avoids breaking the OS! You want to leave the Catalina libraries in place for 64 bit applications. I suspect Catalina won't even boot if you replace most/all of the libraries with the versions from Mojave. (You'd have to replace even the libraries that are 64-bit only, because the Mojave version of library X will depend on the Mojave version of library Y, which depends on the Mojave version of library Z, and so on.) And even if it did boot by some miracle, and that point you'd basically be running Mojave, so do that!

I suppose you could manually go through and take the 32bit slices from Mojave and lipo them to the 64 bit slices in Catalina, but... why? It's just a lot of work for no clear purpose. It makes more sense to use DYLD_ROOT_PATH.

I would love to meet those people…

Also, in defence of that project’s endeavour, there wasn’t a boot-args variable to enable a more complete (or robust) degree of support for PowerPC functionality within the developer builds of Snow Leopard. That alone, with respect to Catalina, indicates there was a reason internal developers at Apple kept that flag around beyond the official sunsetting of 32-bit application access.

I know you're involved in it! It's a really neat project.

The problem is, all the boot argument does is allow 32 bit binaries to load. And that's great for simple binaries! You might even have luck with more complex applications if they're statically linked, such as anything written Go—but I don't think Go even supports 32 bit on macOS.

Basically everything of significance needs system libraries to work, and those are simply gone in Catalina.

I'm really sorry to rain on the parade, I also hate how Apple killed 32 bit apps, and it's one of the things that pushed me away from modern macOS altogether. But I just don't see how this can possibly work, and so frankly I'd like to save you all the time.

I am curious whether anyone can actually get apps running via the DYLD_ROOT_PATH method! You should try that first anyway, as it represents the best case scenario for what is possible.

But this is to say there was even more, beyond libraries, which got pulled from Catalina.

No, it's just the libraries, but those libraries are basically the whole thing. Like, an OS consists of a kernel and userspace. And most of userspace is the libraries.

 

[B S Magnet]

Because it avoids breaking the OS! You want to leave the Catalina libraries in place for 64 bit applications.

Quite honestly, I hadn’t fathomed those Mojave dylds for 32-bit binaries would be overwriting any of Catalina’s dylds, or else I wouldn’t have brought that up as a question.

I suspect Catalina won't even boot if you replace most/all of the libraries with the versions from Mojave.

I imagine not.

I suppose you could manually go through and take the 32bit slices from Mojave and lipo them to the 64 bit slices in Catalina, but... why? It's just a lot of work for no clear purpose.

This is, I suppose, why we’re having this discussion — not only for our own benefit and understanding, but for any who might find themselves asking some of these same questions down the way.

The problem is, all the boot argument does is allow 32 bit binaries to load. And that's great for simple binaries! You might even have luck with more complex applications if they're statically linked, such as anything written Go—but I don't think Go even supports 32 bit on macOS.

This makes sense.

Basically everything of significance needs system libraries to work, and those are simply gone in Catalina.

I'm really sorry to rain on the parade, I also hate how Apple killed 32 bit apps, but I just don't see how this can possibly work, and so frankly I'd like to save you all the time.

I am curious whether anyone can actually get apps running via the DYLD_ROOT_PATH method!

What exactly is the mechanism which would make the DYLD_ROOT_PATH method work without it negatively impacting the means to launch Catalina-supplied system applications )or any third-party applications deployed for 10.15 and up) which need those Catalina-minimum libraries?

In other words, with the DYLD_ROOT_PATH mod in place, how might an application be able to select the correct dyld if, say, the same library existed, with same file name (as many do), in both Mojave and Catalina, albeit only one of those — the former — has 32-bit support? I would think, say, with that in place, a 10.15+ application might seg fault when the needed dylds point to those from Mojave.

In any case, someone else here will have to try out that method on their setup, as I don’t have anything running Catalina.

 

[Wowfunhappy]

I hadn’t fathomed those Mojave dylds for 32-bit binaries would be overwriting any of Catalina’s dylds, or else I wouldn’t have brought that up as a question.

Libraries in Mojave are universal binaries, just like in the PPC days. The only difference is that instead of a PPC slice and an Intel slice, the library has a 32 bit Intel slice and a 64 bit Intel slice.

So /usr/lib/libc++.1.dylib exists in both Mojave and Catalina, and in Mojave, technically the same file is used by both 32 bit and 64 bit applications. But in Mojave, a 32 bit app will load the 32 bit slice, and a 64 bit app will load the 64 bit slice. In Catalina, there is no 64 bit slice.

Again, you could lipo the 32 bit slice from Mojave with the 64 bit slice from Catalina, I just don't see the point versus leaving them as separate files and setting DYLD_ROOT_PATH on a per-app basis.

In other words, with the DYLD_ROOT_PATH mod in place, how might an application be able to select the correct dyld if, say, the same library existed, with same file name (as many do), in both Mojave and Catalina, albeit only one of those — the former — has 32-bit support?

An app loaded with the DYLD_ROOT_PATH environment variable pointing to Mojave libraries will only load Mojave libraries, and ignore all Catalina libraries. This is the purpose of setting DYLD_ROOT_PATH.

This is what needs to happen anyway in order to run a 32 bit app, because a 32 bit app can only load 32 bit libraries, and Catalina does not provide any 32 bit libraries. So the Catalina libraries are entirely useless to the 32 bit app.

I would think, say, with that in place, a 10.15+ application might seg fault when the needed dylds point to those from Mojave.

You're going to have trouble finding a 10.15+ 32bit application. Presumably, you wouldn't set DYLD_ROOT_PATH when loading a 64 bit app.

But there's a bigger problem: with DYLD_ROOT_PATH set you're still using the Catalina kernel. So the question is, to what extent does the Catalina kernel work with Mojave libraries?

My guess would be "not very well", but I don't know.

---

Edit: @B S Magnet , I have made some significant additions to this post as I re-read yours a few times and (I think) honed in on where the misunderstandings lie. If you already started a reply, please take a second look. Sorry if this is annoying, I'm trying my best!

 

[TheShortTimer]

An app loaded with the DYLD_ROOT_PATH environment variable pointing to Mojave libraries will only load Mojave libraries, and ignore all Catalina libraries. This is the purpose of setting DYLD_ROOT_PATH.

This is what needs to happen anyway in order to run a 32 bit app, because a 32 bit app can only load 32 bit libraries, and Catalina does not provide any 32 bit libraries. So the Catalina libraries are entirely useless to the 32 bit app.

How about if, like myself you have Catalina installed alongside Mojave and you want to run a 32-bit program that's present on the Mojave partition, wouldn't there be a way to map Catalina to access the relevant libraries from the Mojave partition and run the program?

 

[Wowfunhappy]

How about if, like myself you have Catalina installed alongside Mojave and you want to run a 32-bit program that's present on the Mojave partition, wouldn't there be a way to map Catalina to access the relevant libraries from the Mojave partition and run the program?

Yeah, use DYLD_ROOT_PATH! So you'd boot Catalina, open a Terminal, and run:

DYLD_ROOT_PATH="\Volumes\<MacOS_Mojave_Root>" /Path/To/my32bitApp.app/contents/MacOS/my32bitApp

If this by some miracle this ends up actually working reasonably well, we can discuss ways to make it more seamless, such as by setting LSEnvironment in info.plist. At the moment, I'm skeptical that anyone will be able to find an app that doesn't just crash on launch, due to mixing Mojave userspace with a Catalina kernel.

 

[ojfd]

If you want to see which libraries specifically are needed, that's relatively easy. Try launching a 32bit app (on a compatible OS like Mojave) with the DYLD_PRINT_LIBRARIES environment variable set to 1. For example:

DYLD_PRINT_LIBRARIES=1 /Applications/iWork\ \'09/Pages.app/contents/MacOS/pages

1. There's more user friendly way to determine dependencies

GitHub - kwin/macdependency: MacDependency shows all dependent libraries and frameworks of a given executable, dynamic library or framework on Mac OS X

MacDependency shows all dependent libraries and frameworks of a given executable, dynamic library or framework on Mac OS X - kwin/macdependency

github.com

If the library/framework is not present, it will be shown in red.
NOTE. You also have to check dependecies of all libraries and frameworks that reside inside the application package

2. If all libraries/frameworks check out OK, try to launch the application by directly double clicking on executable. It will run in Terminal and, if something is missing (symbols, for example) or lib/framework has wrong architecture, you will be greeted with error log.

More later..

 

[TheShortTimer]

Yeah, use DYLD_ROOT_PATH! So you'd boot Catalina, open a Terminal, and run:

DYLD_ROOT_PATH="\Volumes\<MacOS_Mojave_Root>" /Path/To/my32bitApp.app/contents/MacOS/my32bitApp

If this by some miracle this ends up actually working reasonably well, we can discuss ways to make it more seamless, such as by setting LSEnvironment in info.plist. At the moment, I'm skeptical that anyone will be able to find an app that doesn't just crash on launch, due to mixing Mojave userspace with a Catalina kernel.

I tried to have a crack at this but I encountered problems at the most basic level.

From what I've read, the SIP needs to be disabled first but I'm unable to do this because CMD+R loads the recovery option for Lion, whose Terminal doesn't even recognise the csrutil command anyway. If I attempt to boot Catalina's recovery partition by holding down Option, the prohibitory symbol is displayed and then the computer shuts down soon after.

Is there no other way to run sudo nvram boot-args="no32exec=0" without disabling SIP first?

 

[Wowfunhappy]

Is there no other way to run sudo nvram boot-args="no32exec=0" without disabling SIP first?

SIP is the "no fun allowed" setting . You're going to have to get that turned off before playing with any of this stuff. I don't think you can set DYLD_ROOT_PATH while SIP is enabled in the first place.

Perhaps you can create a USB installer for a 10.11+ version of macOS, boot that, open the Terminal, and run csrutil --disable there?

 

[TheShortTimer]

SIP is the "no fun allowed" setting .

I like that description!

Reminds me of this John Landis comedy...

SIP is supposed to protect you from malicious attacks though?

Perhaps you can create a USB installer for a 10.11+ version of macOS, boot that, open the Terminal, and run csrutil --disable there?

I've got the recovery partition for Mojave and it works. If I disable SIP within there it'll also disable it for the Catalina installation too?

 

[Wowfunhappy]

SIP is supposed to protect you from malicious attacks though?

Yeah, so it goes. If you can't mess with the internals of your operating system, neither can anyone else. 🤷‍♂️

I've got the recovery partition for Mojave and it works. If I disable SIP within there it'll also disable it for the Catalina installation too?

Yes! On Intel Macs, SIP is system-wide (because it's stored in NVRAM).

 

[nathansz]

Arising from a discussion aside to come up on another thread, @TheShortTimer suggested this question be spun off into a new thread.

Even as Apple formally withdrew support for running 32-bit applications from Catalina forward, the ability to use 32-bit binaries in Catalina persisted with the inclusion of an nvram boot-args setting, as mentioned by @Dayo earlier in the same thread. Indeed, this discovery, originally reported by the Hackintosh community’s netkas, has been known since 2019.

There are selected dynamic libraries which would need to be sourced from, optimally, the final version of Mojave, to help facilitate the running of 32-bit binaries, but the key word here is binaries — not the usual clicking of an “Application.app”, et voilà, 32-bit applications play nice on Catalina. Which libraries those are is less clear, as the only suggestion is to link the entire dyld directory location from Mojave to Catalina. There hasn’t, so far, been a more selective means of managing this — to pick only those libraries needed and nothing more.

There may, however, be a way to make this happen. That’s what this topic hopes to invite.

What that thread (nor any source we’ve been able to find so far) was unable to answer is which libraries and/or frameworks, sourced from Mojave, may permit the running of 32-bit applications in Catalina? Assembling that list of needed libraries — to pull only those libraries needed — is what this thread can discuss.

This legacy capability may be valuable for users of specialized software which either was never ported to 64-bit or is tied to external hardware for which their ongoing utility is still handy, but software support for them is frozen in the time the product was current. A couple of good examples include utilities for legacy MIDI devices and dedicated film scanners.

(I post this with self-awareness this task may not actually be possible.)

Anyhow, if healthy participation warrants it, I can convert this to a wikipost. Cheers.

Not in the spirit of the thread, but I just use a mojave vm for 32 bit stuff

Seems much simpler to me

 

[B S Magnet]

Not in the spirit of the thread, but I just use a mojave vm for 32 bit stuff

Seems much simpler to me

If it works for you, then go for it.

For my needs, it’s a kludge in either direction. Running 32-bit midi hardware via a VM is, rarely, a smooth setup. Latency is a big factor. Running a Catalina or later VM from Mojave or earlier, meanwhile, impacts the means to use audio/video services on online applications like Signal (and also an issue of increased latency and/or dropped frames).

A VM, even if native i386/x86_64 architecture, is still your hardware running two or more systems — host and guest(s). Two running copies of macOS, even on Macs with 16GB RAM on hand, takes a hit with that.

 

[Amethyst1]

If it works for you, then go for it.

Seems the best way to go for your needs is two separate Macs (or volumes, if you don't need both to run at a time), one running Mojave or another 32-bit-app-friendly version, the other running Catalina or a later version.

 

[TheShortTimer]

Yes! On Intel Macs, SIP is system-wide (because it's stored in NVRAM).

Thanks. From Mojave's recovery partition, I set the 32-bit flag and disabled SIP.

Yeah, use DYLD_ROOT_PATH! So you'd boot Catalina, open a Terminal, and run:

DYLD_ROOT_PATH="\Volumes\<MacOS_Mojave_Root>" /Path/To/my32bitApp.app/contents/MacOS/my32bitApp

If this by some miracle this ends up actually working reasonably well, we can discuss ways to make it more seamless, such as by setting LSEnvironment in info.plist. At the moment, I'm skeptical that anyone will be able to find an app that doesn't just crash on launch, due to mixing Mojave userspace with a Catalina kernel.

Attempting to run 32-bit software installed in Mojave from Catalina using the DYLD_ROOT_PATH method resulted in crashes - regardless of whether the program has the prohibitory symbol or not. I also tried to do the same with software installed in Snow Leopard and received a "bus error: 10" message in the Terminal on Catalina.

Perhaps others who have Catalina/can install Catalina and play around with this might have better luck?

 

[B S Magnet]

Seems the best way to go for your needs is two separate Macs (or volumes, if you don't need both to run at a time), one running Mojave or another 32-bit-app-friendly version, the other running Catalina or a later version.

:: whingey-poutey voice :: But I don’t wanna have to carry two laptops or flip back-and-forth all the time. Gosh, why couldn’t Apple have just let the poor little i386 libraries just live on? It was harmless and not hurtin’ nobody! :: whingey-poutey voice persists as I walk out of the room. whingey-poutey voice grates on people’s ears ::

 

[Dayo]

Example targets include utilities for legacy MIDI devices and dedicated film scanners.

There is a good chance many such small and presumably relatively self contained utilities would work with just the flag.

Here is a report on a small utility that apparently works with just the flag set:

Activate AMD hardware acceleration

Mainly SubFix, I know there are some 64bit alternative options our there. I tried, but doesn't work as good as SubFix.

forums.macrumors.com

I don’t wanna have to carry two laptops or flip back-and-forth all the time.

I run Mojave installed stuff from BigSur all the time on my MP31. Obviously not 32-bit items but you get the idea.

Your soon-to-be-unveiled "Ultimate Universal Catalina 32-bit Enabler" would extend this to 32-bit stuff.
Can't wait ... especially since I already have had the no32Exec flag set in Opencore (MyBootMgr does this by default).

 

[B S Magnet]

There is a good chance many such small and presumably relatively self contained utilities would work with just the flag.

Sure.

I don’t have a need to run ls, grep, cp, or whatever else from a 32-bit binary when there have been 64-bit-compliant binaries for these at every turn since Snow Leopard. It’s also not central to why I posted this topic.

Here is a report on a small utility that apparently works with just the flag set:

Activate AMD hardware acceleration

Mainly SubFix, I know there are some 64bit alternative options our there. I tried, but doesn't work as good as SubFix.

forums.macrumors.com

I run Mojave installed stuff from BigSur all the time on my MP31. Obviously not 32-bit items but you get the idea.

This isn’t really relevant to the use-case being presented by this topic.

Your soon-to-be-unveiled "Ultimate Universal Catalina 32-bit Enabler" would extend this to 32-bit stuff.
Can't wait ... especially since I already have had the no32Exec flag set in Opencore (MyBootMgr does this by default).

Cool.

The point of opening this thread is to invite and collect together, definitively, all known aspects of undocumented/deprecated-but-still-present 32-bit binary/application functionality in Catalina and — this is key — to collect together folks who decide to volunteer testing what the limits of those aspects are. That’s it. This isn’t a “soon-to-be-unveiled”-anything.

You may not be a frequent regular to the EIM forum. That’s OK.

This is how folks on this and the older, PowerPC forum do things: we put minds together and we try to understand how and why things work the way they do. Sometimes we manage to find ways to do something which was written off previously as un-doable. We all bring different skill sets, and every contribution works toward that community-led collaboration and informal mandate.

If you want to play a card of condescension, there are dozens of other MR sub-forums where that’s the tacit entry fee. You’ll have no one here to indulge or spar with you on that level.

 

[Dayo]

Dont play a condescension card. This isn’t a “soon-to-be-unveiled”-anything.

I was just being a bit lighthearted. I happen to know that you have pulled stuff out of your hat in the past and hoping you can repeat the trick again ... while knowing it is obviously a big task (if even possible as an overall thing). I do appreciate that tone does not translate in written text though. Will cut out the wise cracks.

I don’t have a need to run ls, grep, cp, or whatever else from a 32-bit binary

The types of stuff you mentioned as good candidates are not at that level and are useful stuff but many are not updated to 64-bit. I believe SubFix was similarly never updated but for many, far better than options currently available.

 

[Wowfunhappy]

Attempting to run 32-bit software installed in Mojave from Catalina using the DYLD_ROOT_PATH method resulted in crashes - regardless of whether the program has the prohibitory symbol or not. I also tried to do the same with software installed in Snow Leopard and received a "bus error: 10" message in the Terminal on Catalina.

Yep, unfortunately this is about what I expected to happen, and almost certainly the end of the road unless someone finds a copy of most of macOS's source code and can recompile everything as 32 bit. (Or Large Language Models allow us to make near-perfect decompilers or something.)

---

If anyone is itching for a project to improve backwards compatibility on macOS which may actually be achievable, I have a theory that it may be possible to get Rosetta working on 10.7+. Rosetta support was removed from the kernel, but unlike the system libraries being discussed in this thread, the kernel is open source and it's really quite easy to compile your own custom version. (And Rosetta probably doesn't rely on PPC system libraries, since it's intended to be a high-level emulator which translates as little code as possible.) So just look at the code Apple took out and put it back in.

 

[B S Magnet]

Yep, unfortunately this is about what I expected to happen, and almost certainly the end of the road unless someone finds a copy of most of macOS's source code and can recompile everything as 32 bit. (Or Large Language Models allow us to make near-perfect decompilers or something.)

---

If anyone is itching for a project to improve backwards compatibility on macOS which may actually be achievable, I have a theory that it may be possible to get Rosetta working on 10.7+. Rosetta support was removed from the kernel, but unlike the system libraries being discussed in this thread, the kernel is open source and it's really quite easy to compile your own custom version. (And Rosetta probably doesn't rely on PPC system libraries, since it's intended to be a high-level emulator which translates as little code as possible.) So just look at the code Apple took out and put it back in.

Personally, at this particular moment, I’d prefer finding a way to backport the current source for Signal to compile and run in Mojave, but that is also unlikely to come to pass.

 

[f54da]

>"bus error: 10" message in the Terminal on Catalina.
Probably start with something simpler: a CLI app linked only against libc for instance, and work your way upwards to something more complex. As wowfun noted on osx libc is tightly coupled to kernel, and Catalina in fact had a lot of breaking changes, most notably a complete overhaul of pthreads internals to use unfair mutex everywhere (and the introduction of an equivalent to linux's futex). The syscall numbers also not stable, and they can/do make breaking changes.