[cfe-dev] Objective-C blocks with a static runtime on Windows

[vit9696 via cfe-dev]

Thank you for pointing this out.
That is a pretty interesting workaround and it actually seems to work, although the idea itself feels reasonably unobvious.
For the existing compilers it is probably ok to use, but having a flag in the future will likely be saner.
Still, it probably needs to be discussed with objfw staff form now on.

> 3 июля 2017 г., в 19:57, Saleem Abdulrasool <compnerd at compnerd.org> написал(а):
> 
> I think that having a flag is fine.  We already have a link time flag for static libc++/libc.  Pulling that into the compile time and adding a flag for the blocks runtime seems reasonable to me.
> 
> However, it's for user code that static blocks runtime would be more challenging to support. For the runtime itself, it's actually a matter of ensuring that you have the right DLL storage annotations.
> 
> extern __declspec(dllexport) long _NSConcreteStackBlock[];
> void f(void) {
>   __block int i;
>   void (^b)() = ^{ ++i; };
> }
> 
> That seems to compile properly on trunk and not give you import storage on _NSConcreteStackBlock.
> 
> On Mon, Jul 3, 2017 at 6:26 AM vit9696 via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> Hello,
> 
> At this moment it is not possible to use blocks when linking to a static Objective-C runtime on Windows due to a patch applied in r271138 (http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160523/160244.html <http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160523/160244.html>).
> 
> The idea of the patch appears to enforce dynamic linking with NSConcreteStackBlock, but this only results in an undefined reference to `__imp__NSConcreteStackBlock' when linking statically (with e.g. objfw).
> 
> There is a TODO in the added code, however, how can it be called a todo, when the added hack simply breaks block support when linking to static runtimes? It worked just fine before.
> 
> From what I understand the issue for no static block support is due to detection issues: there seems to be no obvious way to detect the runtime type until the linking step.
> 
> Will it be ok to add an extra argument (e.g. -fblock-static-runtime) to disable the hacked code? Or could there be any other solution?
> 
> Vit
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170703/c64fc5f3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170703/c64fc5f3/attachment.sig>