Build on m1 macOS 11.3

[lucyllewy]

Lightly tested: I have succeeded in compiling and executing a hello-world on my m1 MacBook Air. Please treat with extreme prejudice and test it hard, and on other systems than m1 Mac, to ensure I haven't broken things :-)

• CMakeLists.txt:
  • Remove hard-coded x86_64 in macOS builds
  • Set CMake Policy CMP0068 (RPATH on macOS) to NEW
  • Ensure that NekoTargets.cmake is set to append in export(TARGETS command for nekoml to appease newer CMake
  • Drop duplicate arch64 detection block

Possibly fixes #221 Fixes #215

Signed-off-by: Daniel Llewellyn diddledan@ubuntu.com

[Uzume]

Maybe I am wrong here but this PR as it sits right now seems to kill 32-bit Intel builds for macOS. Does homebrew also no longer support such? I realize Apple might not support such much but I do not see a reason to exclude such from neko builds.

I also think it would be better to port libs/ui/ui.c from the old Carbon interfaces to the Cocoa ones since Carbon has gone away (instead of hackishly declaring things like RunApplicationEventLoop and QuitApplicationEventLoop manually for 64-bit targets).

[tobil4sk]

@Uzume The fix for libs/ui/ui.c was already applied in #218... If what you're suggesting isn't too complicated then you could open a PR to make a better fix, however otherwise neko is now deprecated so large ports are probably not likely to happen.

As a side note, in case this PR is updated in the future, the fixes to libs/ssl/ssl.c have also been applied in #239 as they were necessary for mac in general.

[Uzume]

@tobil4sk Yes, I noticed some of the changes had already been merged but thanks for calling them out with links to the other PRs. I see @diddledani just rebased the changes here to fix such.

I am not in a position to work on a Carbon to Cocoa port for libs/ui/ui.c as I do not have a macOS build environment available to me for development and testing but maybe one day.

[tobil4sk]

The libs/std/process.c fix had also been done in #219, however not on the same line so git didn't pick it up, now signal.h is included twice in that file.

[lucyllewy]

Thanks for the ping about the changes already included. I've updated the PR with a rebased copy to include the changes from the main branch so that there isn't any duplicated code - I saw that I had to edit the ui.c (and also as pointed out in comment above by @tobil4sk process.c) file because my change and the one committed already were conflicting due to being changed on different lines; I've dropped my change.

[lucyllewy]

The libs/std/process.c fix had also been done in #219, however not on the same line so git didn't pick it up, now signal.h is included twice in that file.

oops, I missed that one. Thanks for pointing it out. I've pushed again with my change there dedpulicated.

[Uzume]

@diddledani I think you would be better off not removing the 32-bit Intel macOS build target and instead just adding the 64-bit M1 build target. Neither of those platforms currently is fully supported here by the Azure Pipelines checks (which likely need to be updated).

You probably should not test the value of CMAKE_OSX_ARCHITECTURES as parsing it is non-trivial; see:

• https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_ARCHITECTURES.html
• https://cmake.org/cmake/help/v2.8.12/cmake.html#prop_tgt:OSX_ARCHITECTURES

I included docs link for cmake 2.8.12 since that is the earliest version supported here. It contains a list of system architectures not a specific single one.

Currently, you will notice this code is failing the MacStatic check:

CMake Error at libs/mysql/CMakeLists.txt:7 (if):
   if given arguments:

     "STREQUAL" "i386"

   Unknown arguments specified

You probably should add a line specifying darwin64-arm64-cc and not removing i386 the target.

[lucyllewy]

Let's see if commit b8ff4db fixes the testsuite. I've readded CMAKE_OSX_ARCHITECTURES and set it to $NATIVE_ARCH_ACTUAL by default.

[Uzume]

That might work but CMAKE_OSX_ARCHITECTURES is used mostly for making fat binaries, e.g., we could change the line to:

set(CMAKE_OSX_ARCHITECTURES "arm64;x86_64") 

Of course the later compares would then always fail. Those should probably be rectified differently (and not use CMAKE_OSX_ARCHITECTURES to determine system arch).

[lucyllewy]

yeah, that's made it worse - now the non static build is broken..

[tobil4sk]

On this line the CMAKE_OSX_ARCHITECTURES string is being evaluated as an empty string... https://github.com/HaxeFoundation/neko/blob/b8ff4db70aa1376b4133e5936e6bb6ef68c6bd87/CMakeLists.txt#L60

Maybe on this line NATIVE_ARCH_ACTUAL doesn't exist for some reason?? https://github.com/HaxeFoundation/neko/blob/b8ff4db70aa1376b4133e5936e6bb6ef68c6bd87/CMakeLists.txt#L10

[Uzume]

You had the right idea: remove CMAKE_OSX_ARCHITECTURES all together.

A quick search of the code shows that arch_64 is only used in one place libs/mysql/CMakeLists.txt for the WIN32 stuff. That should probably be changed to use CMAKE_SIZEOF_VOID_P directly and arch_64 removed everywhere else.

As for libs/mysql/CMakeLists.txt I am not sure but I do not think it should be trying to parse CMAKE_OSX_ARCHITECTURES either. Obviously it needs to have darwin64-arm64-cc added but it needs to use something else to determine that. Maybe CMAKE_SYSTEM_PROCESSOR is the right thing.

[lucyllewy]

ok, I think this should get the build working for now. I think we should add a followup issue/pr for removing the parsing of CMAKE_OSX_ARCHITECTURES with a better mechanism.

[Uzume]

@diddledani You probably could have used CMAKE_SYSTEM_PROCESSOR but at least that works and seems to have passed all the checks. I agree further cleanup could be useful.

[danielo515]

Thanks for making this work on M1 Currently neko works on my M1, but nekotools fails with

❯ nekotools
Uncaught exception - load.c(237) : Failed to load library : /usr/local/lib/neko/std.ndll (dlopen(/usr/local/lib/neko/std.ndll, 0x0001): tried: '/usr/local/lib/neko/std.ndll' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/lib/neko/std.ndll' (no such file), '/usr/local/lib/neko/std.ndll' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')))

Does this PR fix that?