dispatch.h incompatible with gcc / g++ 12

[jcelerier]

$ echo "#include <dispatch/dispatch.h>" > foo.c
$ gcc foo.c 
In file included from /usr/include/dispatch/dispatch.h:32,
                 from foo.c:1:
/usr/include/os/generic_unix_base.h:58:18: error: missing binary operator before token "("
   58 | #if __has_feature(assume_nonnull)
      |                  ^
/usr/include/os/generic_unix_base.h:72:18: error: missing binary operator before token "("
   72 | #if __has_feature(attribute_availability_swift)
      |                  ^
/usr/include/os/generic_unix_base.h:97:18: error: missing binary operator before token "("
   97 | #if __has_feature(objc_fixed_enum) || __has_extension(cxx_strong_enums)
      |                  ^

[barracuda156]

When Ninja is used with Cmake, it fails already on configure:

-- Check for working C compiler: /opt/local/bin/gcc-mp-12 - broken
CMake Error at /opt/local/share/cmake-3.24/Modules/CMakeTestCCompiler.cmake:69 (message):
  The C compiler

    "/opt/local/bin/gcc-mp-12"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libdispatch/libdispatch/work/build/CMakeFiles/CMakeTmp
    
    Run Build Command(s):ninja -f Makefile cmTC_e8fee/fast && ninja: error: Makefile:5: expected '=', got ':'
    default_target: all
                  ^ near here

[oliverepper]

Any chance to use libdispatch with gcc? __has_feature is clang specific, right?

[barracuda156]

Any chance to use libdispatch with gcc? __has_feature is clang specific, right?

Hopefully someone fixes this eventually. It is disappointing when a software cannot be built with the primary compiler.

[cooljeanius]

GCC will implement __has_feature for GCC 14: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=06280a906cb3dc80cf5e07cf3335b758848d488d

[barracuda156]

@cooljeanius We will likely need this one too: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352

[amyspark]

Found this from working on AcademySoftwareFoundation/OpenColorIO#1973, in particular Obj-C blocks being unsupported undefines OS_ASSUME_PTR_ABI_SINGLE_BEGIN. This in turn breaks all sort of includes until reaching libdispatch.

[barracuda156]

@amyspark Re blocks: GCC upstream is aware of the issue but it is not on the top of the list: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352

[barracuda156]

UPD. Sorry, I need more caffeine. I already posted this link above LOL

P. S. There was an old experimental GCC versions which presumably supported blocks, but it was based on 4.x branch.

[cooljeanius]

UPD. Sorry, I need more caffeine. I already posted this link above LOL

P. S. There was an old experimental GCC versions which presumably supported blocks, but it was based on 4.x branch.

Yeah Apple's version of GCC 4.2 had support for blocks, and apparently Mike Stump had a patch based on that version ready to contribute back to the FSF upstream, but then the GPL v3 hit and Apple wouldn't let their employees contribute anymore, so the patch never ended up getting submitted back upstream...

[barracuda156]

@cooljeanius I do not think Apple gcc-4.2 supports blocks, at least it errs out on the code using those (maybe it has some partial support, I am not sure). I have referred to this compiler: https://code.google.com/archive/p/plblocks

[cooljeanius]

@cooljeanius I do not think Apple gcc-4.2 supports blocks, at least it errs out on the code using those (maybe it has some partial support, I am not sure). I have referred to this compiler: code.google.com/archive/p/plblocks

Blocks support was introduced in Snow Leopard when Apple was still using gcc 4.2 as the system compiler; it had to have supported it for the OS to work... (unfortunately my Snow Leopard machine is dead, so I can't produce proof at the moment, but I definitely remember blocks working on it...)

[barracuda156]

10.6 has llvm-gcc and clang. (Well, we can check what it uses for ObjC.)

[cooljeanius]

look at apple-oss-distributions/gcc@e19d86d; it contained some blocks-related changes

[barracuda156]

@cooljeanius It is conceivable that they ported some patches from clang before finally deciding to dump gcc, the question is whether it worked. AFAIK no, at least not properly. The fact that someone went as far as writing a separate compiler just to try supporting blocks is also suggestive: what was the need at all if a stock gcc-4.2 already supported them?

[cooljeanius]

The fact that someone went as far as writing a separate compiler just to try supporting blocks is also suggestive: what was the need at all if a stock gcc-4.2 already supported them?

From the plblocks description page:

Plausible Blocks (PLBlocks) provides a drop-in runtime and toolchain for using blocks in iPhone 2.2+ and Mac OS X 10.5 applications. Both the runtime and compiler patches are direct backports from Apple's Snow Leopard source releases.

(emphasis added)
It's just a backport for Leopard from Snow Leopard; gcc-4.2 would have had to have supported them for the backport to be possible.

[barracuda156]

@cooljeanius Well, that is perhaps verifiable, we have sources. But if the statement is accurate, then it is pretty useless.

By the way, it does not say backports were from gcc. From clang, yeah, I can believe that.

The runtime is based on Apple's original implementation donated to the LLVM project.

[cooljeanius]

@cooljeanius Well, that is perhaps verifiable, we have sources. But if the statement is accurate, then it is pretty useless.

By the way, it does not say backports were from gcc. From clang, yeah, I can believe that.

The runtime is based on Apple's original implementation donated to the LLVM project.

keyword there being the runtime, by which they mean libobjc. So, libojc from llvm/clang combined with compiler from gcc

[barracuda156]

combined with compiler from gcc

10.6.8 has gcc 4.2 v 5646
We have a newer gcc on Tiger: https://ports.macports.org/port/apple-gcc42

Do blocks work on 10.4 and 10.5? AFAIK, no. With the same or newer Apple gcc than 10.6.8.