omnetpp-5.7.x installation stopped working on Apple Silicon

[yvshudrenko]

yevhenii@dhcp16 workspace-test % opp_env install omnetpp-5.7.x
INFO Using specified projects [omnetpp-5.7.x] with effective projects [omnetpp-5.7.x] in workspace /Users/yevhenii/workspace-test
INFO Downloading project omnetpp-5.7.x in workspace /Users/yevhenii/workspace-test
https://github.com/omnetpp/omnetpp/releases/download/omnetpp-5.7.1/omnetpp-5.7.1-src-macosx.tgz
############################################################################################################ 100.0%
INFO Patching project omnetpp-5.7.x
Patching vanilla omnetpp-5.7.1 to omnetpp-5.7.x from git...
NOTE: We are running on an Apple M processor which is not supported natively.
Turning on x86_64 emulation by starting a new shell with 'arch -x86_64 /bin/zsh -i' ...
setenv: line 55: arch: command not found
ERROR The install operation stopped with error: Child process exit code 127
yevhenii@dhcp16 workspace-test % 

My old local installation is still working, but a new one throws this error. Although the arch command is definitely fine:

yevhenii@dhcp16 ~ % arch -x86_64 /bin/zsh --login
yevhenii@dhcp16 ~ % arch
i386
yevhenii@dhcp16 ~ % 

Newer OMNeT++ is not an option, unfortunately, and Docker for opp_env doesn't work with GUI (at least I couldn't get it to). This is latest opp_env:

yevhenii@dhcp16 ~ % opp_env -v
0.29.3.240918

[rhornig]

Even if the arch command would be available, the installation would fail. The reason is that opp_env would run NIX as a aarch64 command and all the dependencies downloaded would be aarch64 binaries. The 5.7 version never supported the aarch64 architecture natively, but rather the setenv script just switched on x86_64 emulation (with the help of the arch command). So you would end with aarch64 dependencies (Qt etc) and an x86_64 based omnet.

I'm not sure what would happen if you switch the architecture FIRST and then try to use opp_env in that shell. I'm not sure whether NIX would handle that properly and pull the dependencies from the x86_64 repo properly. If that is the case, then the compilation MIGHT work. I have to try this out as I never tested it.

[rhornig]

Ohh, gosh. Tried it out. I can see at least 4 reasons why it's not working :( . The major one is that even if you start an emulated x86_64 shell, if you run an application from there that is aarch64 compiled, all its subprocesses will be again aarch64 (which is reasonable) but this gets in the way. The probel is that python that is used to execute opp_env is also aarch64 compiled so all subprocesses tend to switch back to aarch64 mode.

In this particular case I would probably skip opp_env and would just natively install omnetpp 5.7. At least pre 6.0 versions came with all the x86_64 dependencies pre-packaged so you don't have to deal with that.

I acknowledge, that this is a bug that would be great to be ironed out. In short:

Support OMNeT++ versions older than 6.0 to be installed on Apple silicon macs in an x86_64 emulated environment.

[rhornig]

Implementation hint: The opp_env script needs to be aware that this is a special case (i.e. running in emulation) and all subprocesses MUST be launched for the same architecture (even if python itself is aarch64). Also the system propery in NIX files bust be set to system = "x86_64-darwin"; so NIX will be forced to download x86_64 binaries (despite NIX is being an aarch64 binary)

so in short an "i'm running in rosetta2" flag must be introduced.

[yvshudrenko]

Thanks, @rhornig! Native 5.7.1 through Rosetta worked, although I was under the impression I had some Qt issues around a year ago, hence I discovered opp_env in the first place. 😅 Also I forgot to share the OS version, it's Sonoma 14.6.1 (23G93).