Any success running MacOS in bhyve?

zirias@

zirias@

Developer
Did anyone ever succeed running (any version of) MacOS for x86 in a bhyve vm? If so, any pointers what to do to make it happen?

Background: I don't even want to use it. What I really want to do is to (cross-)compile my own software for MacOS. So far, it seems the only way to obtain an SDK for MacOS is by installing X-Code, which only runs on Macs. In my naive mind, I consider it extremely unfair being forced to buy Apple hardware, just to be able to support their OS in my (free and opensource) software. There's no such problem targeting MS Windows, btw. So, any pointers how to cross-compile to MacOS without owning some Apple hardware would be welcome as well ;) Still, for testing, a VM would be nice of course.

Side note: Didn't know where to put this thread. Would a "virtualization" subforum make sense?
 
I believe you need a VM platform that can simulate some various meta-data that makes the OS think it is running on a "genuine" Mac. The SMC (System Management Controller) is one thing it checks.

I doubt bhyve has this, however I believe it is very possible with VirtualBox. There is no reason the following can't work on FreeBSD's port (in particular, you can see the "setextradata" entries).

https://www.howtogeek.com/289594/how-to-install-macos-sierra-in-virtualbox-on-windows-10/

This should work at least until macOS goes entirely with Apple's vendor specific CPU.
 
The problem with that is that you can't have different hypervisors side by side… But maybe my desktop machine might be able to run that Apple stuff in vbox then…
 
Zirias said:
Would a "virtualization" subforum make sense?
Click to expand...
We have one, created not too long ago.

Wasn't there something in the Apple license that prevented anyone from running MacOS in a VM? Or was that for an older version of OS-X. I can remember something in this regard, just not the details.
 
I think you could run one instance in a VM so long as it was on Apple hardware.

For all we know Zirias is running FreeBSD/bhyve on his fancy MacBook Pro ;)
 
SirDice said:
Wasn't there something in the Apple license that prevented anyone from running MacOS in a VM?
Click to expand...
I think there was something like that. The key issue here is Apple trying to prevent running their software on any hardware not manufactured by them. It seems there are ways around that (if vbox can do it), I'm just interested whether it is possible with bhyve…

And of course, the other part of the problem is that they don't publish SDKs in a way usable for anyone. They are "for free" with Xcode, but that requires you to run MacOS, which in turn requires you to buy their overpriced hardware. Heck, I'd even buy a MacOS license if it came at a sane price and would allow me to run it on whatever hardware I like…

I wonder how people can point the finger towards Microsoft while at the same time praising Apple.

Well, end of rant :rolleyes:
 
The enemy of my enemy is my friend?
Way back in the early 2000's Apple was kind of the good guy. They had just switched over to OSX as it was called then, and they were really nice to BSD folks. In Manhattan, they used to provide meeting space to the NYCBUG (NYC BSD User Group), for NYCBUG's monthly (at the time), meetings.

But these days, I think both MS and Apple are pretty much considered evil. Though MS acts more accepting of Linux, it still has all this telemetry stuff in Windows 10, as far as I know.
And not a real ad, but makes me laugh every time I watch it.

View: https://www.youtube.com/watch?v=KlIAg1SJ2uo


As for the original topic, SirDice is correct, Apple only allows it done on Mac hardware. People have made Hackingtoshes, but they seem to break every time there's an upgrade. For awhile, there was a firm selling PC's running Apple at reasonable prices, but of course, Apple put them out of business.
 
Zirias said:
So, any pointers how to cross-compile to MacOS without owning some Apple hardware would be welcome as well ;)
Click to expand...

It might depend on the language, I presume you're not using something like Python or Java. Golang has the ability to cross-compile, IIRC this is how the gohugo project build software for many platforms (macOS, Linux, FreeBSD, OpenBSD, NetBSD, DragonflyBSD, and Windows on a mixture of x86, amd64, and arm architectures).
Another option to you would be to use something like Github Actions or Travis CI to build your project on macOS - both of which offer free options to open source projects.

Not virtualising for local building or testing, but hopefully a little helpful.
 
forquare said:
It might depend on the language
Click to expand...
Right now, it's a library written in C and a GUI using it in C++/Qt.
forquare said:
Another option to you would be to use something like Github Actions or Travis CI to build your project on macOS
Click to expand...
Might be another alternative to look into, thanks. Well, for Windows, I can cross-compile locally on my FreeBSD machine (and of course, for Linux as well). It's a pity I don't find a way to do the same for MacOS…
 
Zirias said:
It's a pity I don't find a way to do the same for MacOS…
Click to expand...
It is why Apple software bitrots pretty bad. Also many of us aren't satisfied by Apple that is pretty much exactly why we are on these forums!

I do recall that unlike gcc, our clang is a cross compiler. You just need to provide it with the correct system libraries (probably extracted from a macOS install).

Check out here the files which have been extracted from the Android NDK to allow for compiling with the base clang.

https://misc.openbsd.narkive.com/X6SlBaCB/android-development-on-openbsd

I'm not sure if this is a working solution, but it would be my attempt (if I didn't have a ratty 2nd hand mac mini laying around as a foot stool)
 
kpedersen said:
I do recall that unlike gcc, our clang is a cross compiler.
Click to expand...
I actually use GCC for my cross-compiles to Windows and Linux. I think the difference is that with GCC, you have to configure it as a cross-compiler at build time, while clang supports different targets at runtime, does this sound correct?
 
Zirias said:
I actually use GCC for my cross-compiles to Windows and Linux. I think the difference is that with GCC, you have to configure it as a cross-compiler at build time, while clang supports different targets at runtime, does this sound correct?
Click to expand...
Oh right. Very true.

Yes, sounds about right. With GCC you need a new build of the compiler for each target. Clang should target all the platforms provided they are compiled in initially (something to check!) without needing to be rebuilt.

My only worry is that Apple has extended their Clang compiler. I wouldn't be too worried about the *.app files. They are really just folders when opened up on other operating system and I believe the *.framework files are also just folders containing static libs. However I am not sure if our clang (in particular the linker) can handle .dylib (rather than .so) files.

Of course Apple also now has that app signing DRM for their vendor specific CPU these days (to only allow your compiled executables to run on your development machine and to prevent distribution outside their AppStore). However you can probably avoid that DRM for a few more years. The Intel CPU build of macOS doesn't enforce this.
 
kpedersen said:
Of course Apple also now has that app signing DRM for their vendor specific CPU these days (to only allow your compiled executables to run on your development machine and to prevent distribution outside their AppStore). However you can probably avoid that DRM for a few more years. The Intel CPU build of macOS doesn't enforce this.
Click to expand...
Hell what. Ok, maybe I just abandon the whole idea and close the one Github issue of someone asking for a MacOS version with "go, buy a computer and install an operating system" :rolleyes:
 
Zirias said:
Hell what. Ok, maybe I just abandon the whole idea and close the one Github issue of someone asking for a MacOS version with "go, buy a computer and install an operating system" :rolleyes:
Click to expand...
Yeah it is a big problem. Once people finally start getting hit by it in a couple of years, there will be a bit of an uproar (although, disappointingly people are fine with this same "developer DRM" mechanism on iOS).

https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

... or, it could make source distribution popular again (because binaries no longer work across machines).
 
mtu said:
At which point Apple would require source code to be signed before allowing users to compile it ;)
Click to expand...
Yep. This is already the case for iOS and that has always been Apple's plan for macOS too. Unfortunately you can't even warn the typical computer user. They just don't understand and those that do, can't reach critical mass to change things.

It is basically a race to the bottom with companies like Apple. Ultimately we will be spending more time "jailbreaking" things rather than actually helping other humans achieve great things.

The best you can do is have the foresight to safeguard yourself. And that means using / migrating to an OS now that has a future. Even if it isn't necessarily as "user-friendly" yet. Ultimately those that are just getting by with "whatever works" are technically part of the problem (not that I particularly care. If anything it is fun to watch the drama when the sh*t hits the fan and charge a high fee to "fix" things).
 
I'm working with some developers to add the virtualization of the MacOS on bhyve. Unfortunately I think that it will be not added soon. Is one of them who explains the reason :

"Bhyve doesn’t emulates the CPU as Penryn. Additionally, it doesn’t emulate all the MSRs. I’m not aware of any method to log all vm-exits of bhyve".

It seems that there is a method to virtualize an old version of Snow Leopard with the bootloader Chamaleon that doesn't require the flag "Penryn",but then it will not work anyway because bhyve does not support the MSRs....
 
You must log in or register to reply here.
Back
Top