Block.h of libobjc2 conflicts with Block.h from libdispatch (and Swift)

[slashbeast]

The libobjc2 installs root level Block.h header that conflicts with libdispatch, which is also provided by Swift on Linux, making it impossible to install both gnustep's libobjc2 and libdispatch (https://github.com/apple/swift-corelibs-libdispatch)

Is there any option to maybe put this header of libobjc2 into subdirectory in new releases?

[davidchisnall]

It's odd for libdispatch to provide it, since I libdispatch doesn't (didn't?) include a blocks runtime. We did before there was another open source one and compiler-rt also provides one but without very good Objective-C interop for non-Apple platforms. All versions of this header should be compatible, so the simplest thing to do is add an option to not install that header. Anyone packaging libobjc2 can simply exclude it from the set of installed files, but I'm also happy to accept a PR that makes manual installs skip it if the user requests it.

[ngrewe]

A while back, we tried to upstream support for libobjc2 into libdispatch, but were shot down because the Swift team insisted on always shipping their bundled version of the blocks runtime. So unless the stance on that on the libdispatch/Swift side has changed, making installation of the header optional seems like the best approach.

[triplef]

So we’ve been using the Swift libdispatch + libobjc2 on Android without any patches (also not https://github.com/apple/swift-corelibs-libdispatch/pull/534), and are using blocks and GCD extensively, and haven’t run into any issues, with libdispatch linking against their libBlocksRuntime. Can one of you elaborate on the differences of the different blocks runtimes, and potential issues mixing them?

And just to put this out there, would it make sense to go the other way around and add support for using libdispatch’s blocks runtime in libobjc2?

[davidchisnall]

I haven't looked at the Swift one but the LLVM one did not include the right hooks for Objective-C interop with anything other than the Apple runtime. This won't matter at all if you use ARC (ARC just generates block destructors that call ARC functions). If this isn't working, then you can't do things like send a -retain message to a block. In EtoileFoundation, we used to have Smalltalk-style -value, -value:, and so on methods declared on blocks that would invoke them if they had matching type signatures so that you could use blocks or any other Objective-C object with the same signature, but Apple never went in that direction and blocks are a pretty tacked-on feature now. In Objective-C++, I tend to use C++ lambdas instead of C blocks, because the ownership semantics are a lot clearer. The _Block_release implementation needs to call out to the ARC implementation if you want __weak pointers to blocks to work - I don't know if you're doing that but it's the only way of cleaning up after some blocks.

[triplef]

Thanks for the explanation @davidchisnall, that’s very helpful! Too bad Apple didn’t take @ngrewe’s patch to allow using the libobjc2 blocks runtime. Not sure if it could help if the PR came from you David with a more technical explanation along the lines of the above as to why this is needed?

[davidchisnall]

I haven't tried using the Swift blocks runtime. It might be possible - I don't know what hooks they provide for blocks support. I'm not particularly attached to keeping a blocks runtime in libobjc2 - we shipped one because it was the only open source one at the time, not because I believe it's the right place for one to live. If Apple's runtime provides useable hooks for integrating with weak references and so on then we should use theirs.

[buzzdeee]

This just did hit me here on OpenBSD amd64 as well. Tested libobjc2 2.2, which finally builds, and produces binaries, that run and don't crash. Up to now, I had libobjc 1.8.1 installed and gnustep-base was linking against libdispatch. Uninstalling and disabling picking up libdispatch make all work. There are only 2 or 3 other ports depending on libdispatch, so I probably get away here with a @conflict marker for the package for the time being. However, it would be nice if things could be de-conflicted one way or another.

[qmfrederik]

Yes, there's a similar situation when packaging GNUstep for MSYS2. GNUstep depends on libobjc2 and optionally libdispatch, both which provide a blocks runtime. Additionally, MSYS2 contains libBlocksRuntime based on compiler-rt.

[ethanc8]

@davidchisnall When building GNUstep, should we patch out libdispatch's own Blocks Runtime and use libobjc2's Blocks Runtime? If so, should we keep a repo which tracks libdispatch's stable releases except that we apply the patch to remove libdispatch's Blocks Runtime? In that case, do we need to build libobjc2 before libdispatch? I'm not exactly sure how all of these dependencies fit together.

[triplef]

We carry @ngrewe’s patch in the Windows and Android toolchains and apply it via the build scripts. Not sure what would be a good setup for other platforms.

I believe libdispatch needs to be built after libobjc2 in order for libobjc2’s blocks runtime to be found.

[davidchisnall]

All of the versions of this header should be interoperable. I thought we added a configuration option to not install ours. That should be sufficient if you have one from another source.

[ethanc8]

If we have a choice, is it better to use libobjc2's or libdispatch's? I heard that libobjc2 had support for using the Blocks as Objective-C objects, while libdispatch's didn't, but I don't know if anything has changed.

[davidchisnall]

The headers should be compatible. We don’t currently have an option to build libobjc2 without the blocks runtime (when we shipped it, it was the only open source implementation). We use the hooks libdispatch exposes for autorelease pools. I’ve not seen what happens if you compile out our blocks runtime and use the libdispatch or clang one. It may just work now, which would mean we could default to not building ours.