Can't build on macOS < 11.0 with JIT enabled

[stez-mind]

Background: I am using the vcpkg port of the library (version 10.40), which gets pulled by another dependency in our project.

So it's not trivial to disable JIT entirely in our case.

The problem seems to be this line that prevents builds for macOS < 11.0 when JIT is enabled:

src/sljit/allocator_src/sljitExecAllocatorApple.c :

static SLJIT_INLINE void apple_update_wx_flags(sljit_s32 enable_exec)
{
#if MAC_OS_X_VERSION_MIN_REQUIRED >= 110000
	pthread_jit_write_protect_np(enable_exec);
#else
#error "Must target Big Sur or newer"
#endif /* BigSur */
}

I'm not an expert on this, but it looks like that call is only required for M1/M2 processors. Since macOS versions < 11.0 cannot run on arm64, will it be possible to replace the #else branch with a NOP instead of forcing a build failure?

[carenas]

will it be possible to replace the #else branch with a NOP

if the function becomes a NOP then it won't be able to change page permission and you would have crashes instead when trying to generate the JIT code.

FWIW, that code is exclusive to the arm64 port and wouldn't trigger if you were building for Intel.

Is this an universal build?, could you target 11.0 at least for the arm64 part of it?

[stez-mind]

Ok, thanks for the answer.

This is a universal build with host machine arm64. It is fine if we only target arm64 (and there of course 11.0 minimum is not a problem).

[tempelmann]

This can be fixed by replacing the compile-time check with a runtime check like this:

  if (__builtin_available(macOS 11, *)) {
    pthread_jit_write_protect_np(enable_exec);
  }

You may also need to add this include:

#include <AvailabilityMacros.h>

I have used this modification over 10.42 for the past two years in a public program without any issues.

[carenas]

This can be fixed by replacing the compile-time check with a runtime check

Something similar was merged as part of zherczeg/sljit#127 and would be likely in the next release of PCRE2

[tempelmann]

Okay, with the fix in #127 this ticket can be closed, then, I suggest.