MacOS-ARM Development

From Bioinformatics.Org Wiki

Jump to: navigation, search

Mystica Arrow set (with deep) 1.png [return to BIRCH/Release To Do list]

Contents

Background

At present (June 2022) Apple is switching its lower end devices such as MacBook and Mini to the ARM SoC (system on a chip) architecture. The current high end Mac Pro is still x86-64. There is a lot of discussion on the Internet that Apple is designing RISC chip for servers, so the Mac Pro will probably switch to that chip at some point. There is speculation that Apple will try to get back into the server market, and the selling point would be lower power/heat, and in many cases better performance.

For the immediate future, the best and most economical strategy is to buy a Mac Mini ARM and support that platform. BIRCH users who want to use the MacOS will probably also use low-end machines. For higher end work, people will use Linux anyway. My guess is that bioinformatics on high-end Macs will be a very small market share for the next 2 or 3 years.

Maybe the other thing to consider is that the Apple ARM processors are still undergoing some evolution, so you don't want to spend a lot of money now on high end hardware.

Finally, it's not just a question of getting the Mac's out, but the applications (eg. Java, LibreOffice etc.) have to adapt and get polished on that platform. THEN we have another lag period as the bioinformatics applications catch up.

Platform

It turns out that on MacOS the precise terms for platform differ between shell, Java and Python.

zsh 

uname -s
Darwin

uname -m 
arm64

Java
platform.java 

// test to find out OS and architecture
class platform {
    public static void main(String args[]) {
        String osName = System.getProperty("os.name");
        System.out.print("OS: ");
        System.out.println(osName);
        String osArch = System.getProperty("os.arch");
        System.out.print("arch: ");
        System.out.println(osArch);
    }
}


Output

java platform
OS: Mac OS X
arch: aarch64


Python 

>>> import platform
>>> platform.system()
'Darwin'
>>> platform.machine()
'arm64'
>>>

Applications

BONUS: Once we get a MacOS-ARM64 machine, we can use the same machine to produce a Linux-Arm version of BIRCH using Linux VMs.

Application To Do List

lib-macos-arm64 - Many of the appications need libraries lib-$BIRCH_PLATFORM. The right way to do this is to create an empty lib-macos-arm64, and to initially populate it as a list of symbolic links to directories in lib-osx-x86_64. That way, we can first change scripts that set the libraries so that they point to lib-$BIRCH-PLATFORM, and will not have to be changed a second time.
Next, we slowly replace symbolic links with native binaries, and ultimately will have a complete lib-macos-arm64 collection.


The following applications don't run or give error messages:

BioLegato Runs, but gives this message: ​Did not detect your system architecture: aarch64

lbirchdb 

Traceback (most recent call last):
 File "/Users/frist/BIRCH/script/lbirchdb", line 7, in <module>
   birchace.call_ace(os.path.join(birchenv.BIRCH, 'local', 'public_html', 'birchdb'))
 File "/Users/frist/BIRCH/script/birchace.py", line 74, in call_ace
   if ACEFONTS != "" :
UnboundLocalError: local variable 'ACEFONTS' referenced before assignment

BLHelper Test button fails to work for

Jalview Needs Java8 

/Users/frist/BIRCH/script/jalview: line 9: /Users/frist/BIRCH/lib-macos-arm64/jre8/jre/bin/java: No such file or directory

This can be fixed by making lib-macos-arm64 a symbolic link to lib-osx-x86_64. As a permanent fix, we need to be populating lib-macos-arm64 with native arm64 libraries. Where that is not possible, we need to modify scripts to use lib-osx-x86_64 on a case by case basis.

lib-macos-arm64/jre8 can be used by any legacy Java program (eg. Mauve) that still needs Java8.

ncbiquery.py
Needs BioPython. Best solution is to add BioPython to lib-macos-arm64. However, a quick fix is to edit the ncbiquery, seqfetch and protfetch bash scripts 

case $BIRCH_PLATFORM in
   linux-x86_64)
       PYTHONPATH=$BIRCH/lib-linux-x86_64/python/lib64/python3.5/site-packages
   ;;
   osx-x86_64|macos-arm64)
       PYTHONPATH=$BIRCH/lib-osx-x86_64/python/lib/python3.7/site-packages
   ;;
esac

spades - fails to run <p> cutadapt - not found <p> blsort - fails to run

BIRCH

Especially because of the internal inconsistency among shell, Java and Python, let's use a BIRCH-wide name that makes sense in the end-user context. There is no perfect answer to this, so anything we do is a compromise.

binaries

How do we do binaries? For some time, there will be binaries that are easy to re-compile on arm64, and others that may never recompile, or for which we have to wait for developers to create binaries.

While it is not obvious how to deal with this problem, one way is to download two sets of binaries on macos-arm64: bin-macos-arm64 and bin-osx-x86_64. If both are in the path, and bin-macos-arm is first in the path, then if the arm version is available it will run, but it it's not found there, the shell will use the x86_64 binaries under rosetta2. This lets us create a release soon, and over time eliminate more and more of the legacy x86_64 code. We would have to modify the install scripts to work with both sets of binaries on arm64 systems.

From this discussion, it is likely that we will have to make rosetta2 a requirement for birch on macos-arm64 platforms.

bin-macos-arm64

lib-macos-arm64

Retrieved from "http://www.bioinformatics.org/wiki/MacOS-ARM_Development"
Personal tools
Namespaces
Variants
Actions
wiki navigation
Toolbox