compile issue on iOS in Xcode

[digitalgust]

iPhone can't using jit , but my program is cross platform application, so i need compile pass in iOS, although i've disabled jit on iOS.
the "SLJIT_UPDATE_WX_FLAGS" is not defined.
env: macOS Xcode iPhone12PM, arm

[zherczeg]

@carenas maybe can help to you.

So your code contains the jit compiler even if it is unusable? Why not guarding it out in some way? This sounds very inefficient since it increases the code size for nothing.

[digitalgust]

Because sljitLir.h is referenced in many places, sljitLir.c needs to be compiled into the project. Therefore, I hope the entire project can be compiled successfully. When defining macros, add an #else to adapt to other architectures or CPU types.

[carenas]

When defining macros, add an #else to adapt to other architectures or CPU types.

in this case though the omission was intentional (see #156), because IMHO it is better to break the build than compile code that WILL crash if invoked.

maybe the problem for your codebase is that you are including sljitLir.h in too many places and should had instead included sljitLir.c in the single place where SLJIT is being used?

[digitalgust]

sljit itself is a tool library for cross-platform and cross-architecture, so I think it would be more convenient for sljit users if it can be compiled on all platforms. Therefore, I suggest that it should be able to be compiled on the IOS platform. The early versions of sljit did not have this problem. Recently, after I updated to 0.95, the problem occurred. Although I can add a line #define SLJIT_UPDATE_WX_FLAGS(from, to, enable_exec) at line 108 of the sljitExecAllocatorApple.c file to solve the problem, as a super excellent tool, it would be better to solve such problems.

[zherczeg]

I am ok to change this. However, the problem, that the compiler will not work if you accidentally run it still persists. There is one more thing: on cpus which the compiler does not support will also throw a compiler error.

[carenas]

FWIW SLJIT could be made to work in iOS (AFAIK it does work, or at least used to in rooted devices AS-IS), and indeed the lack of this definition is an invitation to add the code that is missing to do so (see PCRE2Project/pcre2#212 for some ideas that failed to materialize).

as you pointed out, there is nothing preventing YOU to add an empty define instead and move on, as far as you understand the risks, and as @zherczeg explained, that it will be also inefficient (and maybe even a security concern) to carry extra code that is not in use.

indeed, I wouldn't be surprised if Apple will later reject your app, because it has references in the code to "dangerous" APIs that go against their stated policies.

[digitalgust]

Thank you, I have excluded sljitLIr.c as a source file in the project, and it compiles successfully. However, I still thank you for the reminder and effort. sljit is indeed excellent.