libdispatch: how to make linking to libblocksruntime work?

[barracuda156]

I am trying to make libdispatch port. Configure fails on 10.6.8 (both x86 and Rosetta), not being able to find libBlocksRuntime.

CMake Error at src/CMakeLists.txt:140 (target_link_libraries):
  Target "dispatch" links to:

    BlocksRuntime::BlocksRuntime

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

On Rosetta I tried to link to libblocksruntime port, on x86 it is supposed to exist, but both fail likewise.

Any ideas how to make it work? :)

Another issue: while Ninja is supposed to be used with Cmake, it fails immediately on some parsing error during 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

(Without setting Ninja this error does not occur.)

[barracuda156]

Few attempts on Rosetta:

[barracuda156]

Portfile used:

[kencu (Ken)]

by default the cmake PortGroup sets things up to configure and build for Makefiles, using "make".

ninja has no idea how to build a Makefile, and that is why you see those weird ninja errors. ninja does not speak "Makefile".

to build with ninja using MacPorts cmake PortGroup, you set this:

cmake.generator Ninja

and then everything else is automatic. See <​https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/cmake-1.1.tcl> for all the gory details about how to make the cmake 1.1 PortGroup obey your bidding.

Regarding not finding Blocks, as you can see none of your configure arguments are being used during your build, and you're relying on the built-in Blocks-finding cmake logic in that upstream repo. I guess it is not working -- my first thought is because libblocksruntime doesn't exist on MacOS (it is in libSystem.dylib).

You'll have more success making this work to begin with if you do it on MacOSX 10.5 Leopard, probably Intel, which is where I will try it soonishly.

[kencu (Ken)]

I think the reason the CMakeLists.txt error on finding BlocksRuntime::BlocksRuntime is they don't get this extra definition from this folder they expect.

src/BlocksRuntime/CMakeLists.txt
25:add_library(BlocksRuntime::BlocksRuntime ALIAS BlocksRuntime)

Finding the places where BlocksRuntime::BlocksRuntime is written and changing it to just BlocksRuntime seems to be an easy fix.

However, you don't get too much farther until you run into this:

 fatal error: 'os/availability.h' file not found
#include <os/availability.h>
         ^~~~~~~~~~~~~~~~~~~

and that seems to be due to a requirement for a much newer SDK. Perhaps those headers can just be copied from some newer SDK and used, either into the build itself, or into legacysupport.

But I'm done for this day :>

[barracuda156]

Replying to kencu:

But I'm done for this day :>

Thank you! I will try on 10.5.8, adding suggested fixes.

[kencu (Ken)]

you'll hit the SDK issue with this version of libdispatch...

there may be more success starting out with the libdispatch that was used on 10.6.8 or 10.7.5, and building that. It will be much closer to what 10.5.8 could manage (SDK-wise).

Sometimes you run into a situation where the new libraries require something in the MacOS kernel which the older system's MacOS kernel won't support... if that happens, the fixes are significantly more complicated to implement... not impossible, perhaps, but harder.

[barracuda156]

Replying to kencu:

you'll hit the SDK issue with this version of libdispatch...

there may be more success starting out with the libdispatch that was used on 10.6.8 or 10.7.5, and building that. It will be much closer to what 10.5.8 could manage (SDK-wise).

Sometimes you run into a situation where the new libraries require something in the MacOS kernel which the older system's MacOS kernel won't support... if that happens, the fixes are significantly more complicated to implement... not impossible, perhaps, but harder.

I guess you are right. Will try that.

But if we consider making a port, how to do it? We can have more older version(s) for older systems, like with several other ports, but it is unclear how many we should have and which ones.

16. S. Amazing code from Apple, failing immediately on incompatible flags LOL:

    gcc-mp-12: error: unrecognized command-line option '-Warray-bounds-pointer-arithmetic'
    gcc-mp-12: error: unrecognized command-line option '-Wassign-enum'
    gcc-mp-12: error: unrecognized command-line option '-Watomic-properties'
    gcc-mp-12: error: unrecognized command-line option '-Wcomma'; did you mean '-Wcomment'?
    gcc-mp-12: error: unrecognized command-line option '-Wconditional-uninitialized'; did you mean '-Wno-uninitialized'?
    gcc-mp-12: error: unrecognized command-line option '-Wcovered-switch-default'; did you mean '-Wno-switch-default'?
    gcc-mp-12: error: unrecognized command-line option '-Wdocumentation'
    gcc-mp-12: error: unrecognized command-line option '-Wduplicate-enum'; did you mean '-Wduplicated-cond'?
    gcc-mp-12: error: unrecognized command-line option '-Widiomatic-parentheses'; did you mean '-Wno-parentheses'?
    gcc-mp-12: error: unrecognized command-line option '-Wnewline-eof'
    gcc-mp-12: error: unrecognized command-line option '-Wnullable-to-nonnull-conversion'
    gcc-mp-12: error: unrecognized command-line option '-Wobjc-interface-ivars'
    gcc-mp-12: error: unrecognized command-line option '-Wover-aligned'
    gcc-mp-12: error: unrecognized command-line option '-Wshorten-64-to-32'
    gcc-mp-12: error: unrecognized command-line option '-Wstatic-in-inline'
    gcc-mp-12: error: unrecognized command-line option '-Wsuper-class-method-mismatch'
    gcc-mp-12: error: unrecognized command-line option '-Wunguarded-availability'
    gcc-mp-12: error: unrecognized command-line option '-fblocks'
    

[barracuda156]

Replying to kencu:

You'll have more success making this work to begin with if you do it on MacOSX 10.5 Leopard, probably Intel, which is where I will try it soonishly.

I took a version from 10.6.8, and apparently it will build fine, however when building tests it cannot find dispatch headers (since they are not in the system includes, I guess):

bench.mm:19:30: error: dispatch/private.h: No such file or directory

Header is there, but in libdispatch source. How to deal with this? I guess we want tests to be built. Source here: ​https://opensource.apple.com/release/mac-os-x-1068.html

[kencu (Ken)]

that is some significant progress, if you got it to build. Are you using a Portfile or just building it with Xcode directly, or ???

that looks like it is the right header, just move it or change the reference to it to where the file is looking.

there's another copy here that is probably the same or similar I suspect

​https://github.com/apple/swift-corelibs-libdispatch/commit/89bc4edc352a2a953a84082aa6c1e3935c634add#diff-ca0ed65532783df1d2612f73a6bdd2e1749b3f6394c637c21e0634c1f261c5f4

[barracuda156]

Replying to kencu:

that is some significant progress, if you got it to build. Are you using a Portfile or just building it with Xcode directly, or ???

Turned out we can disable testing for now by setting Xcode target to libdispatch, but the build fails. I attach a log from 10.5.8 below and experimental portfile.

[kencu (Ken)]

I think step one would be to build something on 10.6.8 Intel, if you can.

[barracuda156]

Replying to kencu:

I think step one would be to build something on 10.6.8 Intel, if you can.

Yeah, will try.

I found another implementation of libdispatch in the meanwhile: ​https://github.com/mlba-team/xdispatch ​http://opensource.mlba-team.de/xdispatch/docs/current/index.html

Might be usable, but depends on libkqueue and libpthreadworkqueue (bundled or external), which have no explicit Mac support. External ones: ​https://github.com/mheily/libkqueue ​https://github.com/mheily/libpwq

UPD. Ah, same dependencies like the one you referred earlier to: ​https://github.com/nickhutchinson/libdispatch

[barracuda156]

UPD. Possibly I have fixed libpthreadworkqueue for macOS.

a ./+COMMENT
a ./+CONTENTS
a ./+DESC
a ./._+PORTFILE
a ./+PORTFILE
a ./+STATE
a ./opt
a ./opt/local
a ./opt/local/include
a ./opt/local/lib
a ./opt/local/share
a ./opt/local/share/man
a ./opt/local/share/man/pthread_workqueue.3
a ./opt/local/lib/libpthread_workqueue.dylib
a ./opt/local/lib/pkgconfig
a ./opt/local/lib/pkgconfig/libpthread_workqueue.pc
a ./opt/local/include/pthread_workqueue.h
--->  Activating libpwq @2022.08.01_0

[barracuda156]

In 4112806751e15347024691091558f560b62b8d02/macports-ports (master):

libdispatch-legacy: new port in devel

Closes: #65988