Support AArch64/ARM64, upgrade LLVM and C++ version

[soulofmischief]

This is a draft, I haven't finished committing everything. Not ready for review in its current state. This is no longer a draft.

To enable native Apple silicon support, this PR enables the project to be built with ARM64 architecture. This necessitated a bump in LLVM version, so I bumped to 21.1.7 and rewrote the engine to support ORC JIT.

Additionally, I bumped the C++ version from 11 to 17, matching LLVM. This also allowed us to use the mature filesystem libraries in Windows instead of the experimental ones, but I haven't tested it since I don't run Windows.

I'm not an LLVM expert and this was a weekend hack, so I welcome any feedback. I may have missed something obvious. I think we should put this on a new branch and test it on different platforms, maybe put out an experimental binary before merging into master.

I have only tested it from an Apple silicon macbook. Everything I've tried works the same as before. All core and external tests pass on my machine. I would like to make a few performance optimizations down the road, but this is a good base to start from.

[fetsorn]

Thank you! I tried to do the same LLVM update a year ago and fell short.

I didn't wait for the draft to finish and saw how it would run on asahi linux aarch64. Just hoping to be useful, if any of this is fixed by your commits already then I will check in later.

I encounter an issue similar to https://github.com/audacity/conan-recipes/pull/16/changes. Build fails, portmidi wants explicit imports.

/home/fetsorn/mm/codes/extempore/build/portmidi/src/portmidi/pm_linux/finddefault.c:16:12: error: implicit declaration of function ‘isspac
’ [-Wimplicit-function-declaration]
   16 |     while (isspace(c = getc(inf))) ;

/home/fetsorn/mm/codes/extempore/build/portmidi/src/portmidi/pm_linux/finddefault.c:84:13: error: implicit declaration of function ‘pm_find_default_device’; did you mean ‘find_default_device’? [-Wimplicit-function-declaration]
   84 |         i = pm_find_default_device(pref_str, input);

This error goes away if I build the latest portmidi instead of https://github.com/extemporelang/portmidi

But then I have trouble "moving shared libs into platform-shlibs". The library is in build/portmidi/src/portmidi-build but cmake doesn't want to copy it

[ 57%] moving shared libs into /home/fetsorn/mm/codes/extempore/libs/platform-shlibs
Error copying file "libportmidi.so" to "/home/fetsorn/mm/codes/extempore/libs/platform-shlibs".
make[2]: *** [CMakeFiles/external_shlibs_audio.dir/build.make:73: CMakeFiles/external_shlibs_audio] Error 1
make[1]: *** [CMakeFiles/Makefile2:1029: CMakeFiles/external_shlibs_audio.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

I remember that last year I went around this step by commenting out the copying and manually copying all the built libraries

    add_custom_target(external_shlibs_audio
      COMMENT "moving shared libs into ${EXT_PLATFORM_SHLIBS_DIR}"
      DEPENDS LLVM sndfile kiss_fft portmidi rtmidi
      COMMAND ${CMAKE_COMMAND} -E make_directory ${EXT_PLATFORM_SHLIBS_DIR}
      COMMAND ${CMAKE_COMMAND} -E copy libkiss_fft${CMAKE_SHARED_LIBRARY_SUFFIX} ${EXT_PLATFORM_SHLIBS_DIR}
      #COMMAND ${CMAKE_COMMAND} -E copy libportmidi${CMAKE_SHARED_LIBRARY_SUFFIX} ${EXT_PLATFORM_SHLIBS_DIR}
      #COMMAND ${CMAKE_COMMAND} -E copy librtmidi${CMAKE_SHARED_LIBRARY_SUFFIX} ${EXT_PLATFORM_SHLIBS_DIR}
      #COMMAND ${CMAKE_COMMAND} -E copy libsndfile${CMAKE_SHARED_LIBRARY_SUFFIX} ${EXT_PLATFORM_SHLIBS_DIR}

but linking against the latest portmidi I get an error

Loading xtmaudiobuffer library... Error: evaluating expr: (impc:aot:compile-xtm-file "libs/core/audio_dsp.xtm")
Attempting to return a cptr from a non-cptr obj #f

I patched extempore's version of portmidi, here's the PR: extemporelang/portmidi#1

but i still get the same Attempting to return a cptr from a non-cptr obj error.

i hope any of this is helpful, do tell me if I can do something else to help move this forward.

[soulofmischief]

@fetsorn thanks for the detailed info! I'll look into that and see what I find. I'm going to try to finish sending things up today, I got sick last week :)

I'm pretty sure that as this PR stands now, shared system also doesn't build, but it works fine on my machine. I'll update with what I find about portmidi.

[benswift]

just a heads up (as per my message on the mailing list) I am still working on this - and getting somewhere - it's on the aarch64 branch. Might take a little while & a bit of testing before it lands on master though.

[soulofmischief]

@benswift I'm feeling better today. Lasted longer than I expected. Thanks a bunch for hacking at it in the meantime.

I'll be able to send things up tonight, but I need to force push my branch because I didn't include everything I needed to the first time when combining two local repositories. Several things that were not working in this current branch are resolved locally. I'll clone this branch and replay/review your changes back over this one in case any of them aren't necessary any more or need merging.

[soulofmischief]

@benswift I built extempore locally with CMake 4.x, which doesn't support CMake < 3.5. This required a few changes to get some external projects to build, which I held off on committing. Should we just go ahead and bump the minimum required Cmake version to 3.5 to make builds reliable, or are you or @digego still relying on building with a lower version?

[soulofmischief]

@benswift Actually, seems like quite a lot has changed, so you might be better equipped to test and see what still needs to be merged back over. I moved your changes to https://github.com/soulofmischief/extempore/tree/aarch64-benswift, reset this branch and I'm taking it out of draft, it's ready for review! Everything I've tested works on my platform with this branch.

[benswift]

no worries - I’m knocking off soon but will have a look on Monday.And sorry that I blazed ahead, I have really just taken this opportunity to do a bunch of work that I was planning to do myself anyway. So I really appreciate you kicking it off. I would have been more communicative with you about it if I had known that you were still working on it, but I will have a look at that branch and we will make sure it all lands and extempore builds again across all three platforms :-)CheersBenOn 19 Dec 2025, at 4:19 pm, Blade Dozier ***@***.***> wrote:soulofmischief left a comment (digego/extempore#415) @benswift Actually, seems like quite a lot has changed, so you might be better equipped to merge it back over. I moved your changes to https://github.com/soulofmischief/extempore/tree/aarch64-benswift, reset this branch and I'm taking it out of draft, it's ready for review! Everything I've tested works on my platform with this branch. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[soulofmischief]

I want to make some improvements to better leverage modern LLVM features, reduce the need for all the regexp, etc. there's a lot left on the table since the upgrade.

To better familiarize myself with LLVM first though, I've been implementing my own language using latest best practices. Eventually soon I'll come back and apply that knowledge to this branch.

[benswift]

@soulofmischief yep, I have removed some of the regex/stringy IR stuff in this branch, but there is more that can be done. But I want to get windows working first :)

[soulofmischief]

@benswift Did this break something in Windows? If it's anything big I'm happy to spin up a VM and take a look! I can happily report it's worked great for me so far on my MacBook the last couple of weeks.

[benswift]

I don’t think you broke it per se; it had bitrotted anyway. Have a look at digego/aarch64 a that has my latest stuff in it (and CI checks).