lima-vm
Set the preserve argv0 flag for Rosetta installations on macOS > 13
Description
The current rosetta binfmt_misc code does not set the preserve argv0 (P) flag when registering the binfmt handler. This flag is supported since macOS 14, and Apple even recommends it in their documentation.
This means that programs that look at their own argv[0] will get the actual path that they were called by, instead of the full resolved path that Rosetta would otherwise provide. This fixes some subtle bugs in programs such as clang that look at the path by which they were called to resolve sysroots.
This is a fairly trivial thing to implement, since the set up code only needs to check the macOS version and if it's above 13 it can add the 'P' flag.
This flag is supported since macOS 13
It is supported since macOS 14.
the set up code only needs to check the macOS version and if it's above 13 it can add the 'P' flag.
This is correct. Currently the boot scripts don't have access to he host OS version, so that would need to be provided as well.
Currently the boot scripts don't have access to he host OS version, so that would need to be provided as well.
I think it would be better to export a LIMA_CIDATA_ROSETTA_*** setting, and leave the host OS detection out of boot
I think it would be better to export a LIMA_CIDATA_ROSETTA_*** setting, and leave the host OS detection out of boot
Not sure about this. Given our desire to move code specific to a driver out of core Lima, it doesn't feel right to put Rosetta config code into the cidata package. If anything it should be part of vz.
And if eventually the 05-rosetta-volume.sh script should be supplied by the vz driver instead of being baked into core Lima then it feels better to move the logic there, and just expose the host OS to the boot scripts.
In the past, I encountered unintended behavior in Docker for Mac related to the use of preserve-argv[0] with Rosetta's binfmt_misc. That experience led me to start using Lima.
Here is the link to the issue:
https://github.com/docker/for-mac/issues/7058
I’m not sure how the situation has changed since then, but I hope that the changes proposed in this issue will not introduce similar problems to Lima.
@norio-nomura seems like a tricky issue, but it looks like it might've been fixed in macOS 14 from reading that issue? Not too sure, but maybe if there's a way to configure whether this is used on the lima config it would give us the best of both worlds.
it looks like it might've been fixed in macOS 14 from reading that issue? Not too sure, but maybe if there's a way to configure whether this is used on the lima config it would give us the best of both worlds.
It sounds like that to me too: it is broken in macOS 13, which is why Apple recommends to only enable --preserve=yes in macOS 14 and later.
I would prefer not to create an effectively useless config setting. It would be good if somebody confirm that the bug really is fixed in macOS 14 and 15.