-
Couldn't load subscription status.
- Fork 11
libobjc2: use libBlocksRuntime from libdispatch #58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Because of this, there is no need for a thunk written in assembly to jump to the block body residing in the mprotected page. |
|
Sounds great! Builds are currently failing with: |
|
I know. The header is not in the search path. So this is just a CMake Configuration issue :) |
cef4d41 to
b609d7d
Compare
|
Arggh should build now :D |
|
I will clean up the patches and upstream them into the respective repositories. |
b609d7d to
51fa164
Compare
libBlocksRuntime does not export the symbols correctly when building on Windows. Additionally, libobjc2 has some CMake configuration bugs.
51fa164 to
056c119
Compare
|
Patches can be removed once swiftlang/swift-corelibs-libdispatch#916 and gnustep/libobjc2#355 are merged. |
|
Hmm seems like GNUstep tries to use the GSBlocks compatibility layer, instead of libBlocksRuntime ... gnustep-make requires patching as well. |
|
Breaking Changes:
Open Pull Requests (Patches can be removed once merged): |
Complexity of the Blocks Runtime in libdispatch is lower and only copies the block descriptor not the body. This means we do not need to mprotect a page as -W- and then R-X to execute copied instructions.