<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thank you for pointing this out.</div><div class="">That is a pretty interesting workaround and it actually seems to work, although the idea itself feels reasonably unobvious.</div><div class="">For the existing compilers it is probably ok to use, but having a flag in the future will likely be saner.</div><div class="">Still, it probably needs to be discussed with objfw staff form now on.</div><br class=""><div><blockquote type="cite" class=""><div class="">3 июля 2017 г., в 19:57, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" class="">compnerd@compnerd.org</a>> написал(а):</div><br class="Apple-interchange-newline"><div class=""><div class=""><div dir="auto" class="">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.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">extern __declspec(dllexport) long _NSConcreteStackBlock[];</div><div dir="auto" class="">void f(void) {</div><div dir="auto" class=""> __block int i;</div><div dir="auto" class=""> void (^b)() = ^{ ++i; };</div><div dir="auto" class="">}</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">That seems to compile properly on trunk and not give you import storage on _NSConcreteStackBlock.</div><br class=""><div class="gmail_quote"><div class="">On Mon, Jul 3, 2017 at 6:26 AM vit9696 via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class="">Hello,</div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class="">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 (<a href="http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160523/160244.html" target="_blank" class="">http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160523/160244.html</a>).</div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class="">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).</div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class="">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.</div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class="">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. </div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class="">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?</div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal; font-family: '.SF UI Text'; color: rgb(69, 69, 69); min-height: 20.3px;" class="">Vit</div><div class=""></div></div>_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div></div><div dir="ltr" class="">-- <br class=""></div><div data-smartmail="gmail_signature" class="">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org</div>
</div></blockquote></div><br class=""></body></html>