apple/swift-corelibs-libdispatch

dispatch.h incompatible with gcc / g++ 12

jcelerier opened this issue · 18 comments

jcelerier commented 
$ 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 commented

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 commented

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

barracuda156 commented

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.

amyspark commented

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 commented

@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 commented

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 commented

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 commented

@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 commented

@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 commented

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

cooljeanius commented

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

barracuda156 commented

@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 commented

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 commented

@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 commented

@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 commented

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.