Unable to run readme demo on Mac M1

[Alex-MobileApps]

Problem
Running the code under the "Development on macOS" section of README.md is not running the test project. The final line: "./sktest" is outputting: "no such file or directory: ./sktest" instead of running the test project.

How to reproduce
Using an Apple M1 Mac running macOS 12.2.1, from the terminal run (from README.md):

xcode-select --install
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install cmake
git clone --recursive -j2 https://github.com/splashkit/splashkit.git
cd splashkit/projects/cmake
cmake .
make
cd ../../bin
./sktest

Output
See attached log file log.txt. File ends with "no such file or directory: ./sktest" instead of running the test project.

Expected output
Successful run of the test project

[rickydodd]

It appears the issue may be that you're missing the SplashKit SDK. I suggest typing the following into your terminal emulator:

bash <(curl -s https://raw.githubusercontent.com/splashkit/skm/master/install-scripts/skm-install.sh)

After this, the only thing you will need to re-enter from what you previously entered will be:

cd ../../bin
./sktest

Edit: after re-evaluating, this may not be the solution. But I'll keep it here to try, at the very least. Typing skm into the terminal emulator should also indicate to you whether the SplashKit SDK is installed and pathed to in your environment variables.

[jakerenzella]

@macite Slightly unrelated but what is the status of splashkit on m1 going forward with Apple eventually deprecating OpenGL in favour of vulkan? I'm assuming there'll be some wrapper layer we may be able to switch to?

[isdampe]

Hey @Alex-MobileApps,

I encountered the same issues compiling splashkit-core for M1. You have a few options that I found worked:

1. Use skm and run splashkit through Rosetta (Easiest, if you don't need to edit core)
2. Manually edit CMakeFiles.txt and force the output architecture to be x86_64 (Easier, if you do need to edit core)
3. Manually compile all of the pre-compiled external library dependencies with -arch arm64 and update your CMakeFiles.txt to reflect (Harder, but possible to build natively)

I've cobbled together step 3 and can confirm native ARM builds work, but it's currently fiddly to get working.

@macite mentioned an ideal solution would be to produce universal binaries for all of these libraries that include symbols for both arm64 and x86_64 - meaning native builds would work straight out of the box. I'll be working on this next.

$ lipo -info libSplashKitBackend.a
Non-fat file: libSplashKitBackend.a is architecture: arm64

$ lipo -info sk*
Non-fat file: sktest is architecture: arm64
Non-fat file: skunit_tests is architecture: arm64

$ ./skunit_tests
===============================================================================
All tests passed (22 assertions in 2 test cases)

[macite]

@isdampe if we can get a universal binary created for this that would be great. At the moment we package all of these up in the "external" project with pre-built versions of each of the libraries for mac and windows. This means that others then have easy access to these - but does cost us a little in terms of rebuilding these when new architectures come out and new versions of the libraries we use are created.

@jakerenzella SDL abstracts the graphics library for us at the moment. I assume/hope they will provide a driver to help with this.

[isdampe]

@Alex-MobileApps there's a short-term fix for option 2 in this PR thoth-tech#1