Build errors on 10.6

[barracuda156]

1. There is no support for libdispatch on < 10.6, as well as on 10.6 for ppc (whether native or Rosetta). POSIX or mach semaphores fallback should be used.

:info:build /opt/local/var/macports/build/_opt_PPCRosettaPorts_devel_allegro5/allegro5/work/allegro5-5.2.8.0/src/macosx/hidjoy-10.4.m: In function 'init_joystick':
:info:build /opt/local/var/macports/build/_opt_PPCRosettaPorts_devel_allegro5/allegro5/work/allegro5-5.2.8.0/src/macosx/hidjoy-10.4.m:348:4: warning: implicit declaration of function 'dispatch_sync'; did you mean 'dispatch_sync_f'? [-Wimplicit-function-declaration]
:info:build   348 |    dispatch_sync(dispatch_get_main_queue(), ^{
:info:build       |    ^~~~~~~~~~~~~
:info:build       |    dispatch_sync_f
:info:build /opt/local/var/macports/build/_opt_PPCRosettaPorts_devel_allegro5/allegro5/work/allegro5-5.2.8.0/src/macosx/hidjoy-10.4.m:348:45: error: expected expression before '^' token
:info:build   348 |    dispatch_sync(dispatch_get_main_queue(), ^{
:info:build       |                                             ^
:info:build /opt/local/var/macports/build/_opt_PPCRosettaPorts_devel_allegro5/allegro5/work/allegro5-5.2.8.0/src/macosx/hidjoy-10.4.m: In function 'exit_joystick':
:info:build /opt/local/var/macports/build/_opt_PPCRosettaPorts_devel_allegro5/allegro5/work/allegro5-5.2.8.0/src/macosx/hidjoy-10.4.m:368:45: error: expected expression before '^' token
:info:build   368 |    dispatch_sync(dispatch_get_main_queue(), ^{
:info:build       |                                             ^
:info:build make[2]: *** [CMakeFiles/allegro.dir/src/macosx/hidjoy-10.4.m.o] Error 1

2. Here some header missing?

:info:build In file included from /opt/local/var/macports/build/_opt_PPCRosettaPorts_devel_allegro5/allegro5/work/allegro5-5.2.8.0/src/macosx/qzmouse.m:28:
:info:build /opt/local/var/macports/build/_opt_PPCRosettaPorts_devel_allegro5/allegro5/work/allegro5-5.2.8.0/src/macosx/./osxgl.h:38:4: error: unknown type name 'CVDisplayLinkRef'
:info:build    38 |    CVDisplayLinkRef display_link;
:info:build       |    ^~~~~~~~~~~~~~~~

3. CMakeLists use settings which break Rosetta configure (compilation tests fail due to -msse not being recognized):

if(NOT IPHONE)
    option(WANT_ALLOW_SSE "Allow compiler to use SSE instructions (x86)" on)
endif(NOT IPHONE)

if(CMAKE_SYSTEM_PROCESSOR MATCHES "i.86")
    set(ARCH_X86 1)
endif()

if(ARCH_X86 AND WANT_ALLOW_SSE)
    if(COMPILER_GCC_OR_CLANG)
        message(STATUS "Allowing GCC/Clang to use SSE instructions")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse")
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -msse")
    endif(COMPILER_GCC_OR_CLANG)
. . .
endif()

The problem here is that CMAKE_SYSTEM_PROCESSOR refers to physical cpu, while in Rosetta powerpc arch is emulated by the OS. Correct thing would be use CMAKE_OSX_ARCHITECTURES instead.

[pedro-w]

2. It's part of CoreVideo so #import <CoreVideo/CoreVideo.h> at a guess - weirdly the macOS docs don't seem to tell you which files to include any more (I think they used to?)
   https://developer.apple.com/documentation/corevideo/cvdisplaylinkref?language=objc

[pedro-w]

3. CMake always finds new ways to delight - maybe could you propose a patch for this?

[pedro-w]

1. Tricky. Prior to libdispatch we were using performSelectorOnMainThread and its ilk. It would be quite a bit of work to go back or include #if blocks to select one or the other. Not sure if we're able to support 10.6 and earlier these days, what do you think @SiegeLord ?
   https://developer.apple.com/documentation/objectivec/nsobject/1414900-performselectoronmainthread

[edit] Also weird it denies all knowledge of dispatch_sync but suggests dispatch_sync_f when both are part of the same API.

[barracuda156]

@pedro-w Thank you for responding.

1. It is safe to assume that nothing of libdispatch is supported on any PowerPC, including 10.6.x, despite the header being present (which often confuses build system). Technically, 10.6 PPC (10A190) has some unique defines there, while 10.6.x (released versions) have standard ones, but the issue is that it works only for
   Intel. If something is pulling in dispatch/dispatch.h, it should be protected by a macro (which also excludes __ppc__ explicitly).
   If it is possible to restore your older code as a fallback, that would be great.
   We do not expect any active support for old systems, of course.
2. I will try that, thank you.
3. Yes, that one I can fix and propose a patch, no issues.

[SiegeLord]

If it's possible to keep compatibility in a semi-clean way, it seems like more compatibility is better. But... in this case I wonder if it can be done in a semi-clean way, and what the use case 10+ year old MacOS supported is even if it were possible.