<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 11, 2014 at 4:59 PM, Hovik Melikyan <span dir="ltr"><<a href="mailto:hovik.melikyan@gmail.com" target="_blank">hovik.melikyan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alp,<br>
<div class=""><br>
On Mon, May 12, 2014 at 12:37 AM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:<br>
><br>
> The documentation describes __autoreleasing, __strong and __weak as<br>
> attribute spellings but the implementation provides them as preprocessor<br>
> macro definitions.<br>
><br>
<br>
</div>Actually no, the documentation says: "The names of the ownership<br>
qualifiers are reserved for the implementation. A program may not<br>
assume that they are or are not implemented with macros, or what those<br>
macros expand to."<br>
<br>
<a href="http://clang.llvm.org/docs/AutomaticReferenceCounting.html#spelling" target="_blank">http://clang.llvm.org/docs/AutomaticReferenceCounting.html#spelling</a><br>
<br>
This may lead to unpleasant surprises though, like with MinGW. More<br>
specifically, when clang is in -fms-compatibility mode it doesn't<br>
define __GNUC__ and that in turn makes MinGW think __attribute__ and<br>
some other things should be masked.<br></blockquote><div><br></div><div>You can probably work around this with -D__GNUC__=4.</div><div><br></div><div>However, why do you need -fms-compatibility if you are using MinGW?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the source of confusion here might be that __attribute__ is a "GNU<br>
thing" (correct?), at the same time __weak is not, but relies on it.<br>
<br>
--<br>
H.M.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, May 12, 2014 at 12:37 AM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:<br>
><br>
> On 12/05/2014 02:12, Hovik Melikyan wrote:<br>
>><br>
>> Apologies, my bad, there is no bug. Turns out in certain circumstances<br>
>> MinGW can redefine __attribute__ to do nothing, and as a result __weak<br>
>> becomes either a simple "unsafe" ptr or for certain setups it may<br>
>> become __strong.<br>
><br>
><br>
> Hi Hovik,<br>
><br>
> If that's the case there's still a bug in clang:<br>
><br>
> The documentation describes __autoreleasing, __strong and __weak as<br>
> attribute spellings but the implementation provides them as preprocessor<br>
> macro definitions.<br>
><br>
> I haven't examined why this is the case but one of the two could do with<br>
> fixing (probably the implementation given that this is causing trouble on a<br>
> supported platform). Aaron, any idea what's happened here?<br>
><br>
> Alp.<br>
><br>
><br>
><br>
><br>
>><br>
>> In any case, I decided to go the route of patching clang to accept a<br>
>> new type of -fobjc-runtime. For the time being the patch will be<br>
>> internal of course.<br>
>><br>
>> --<br>
>> H.M.<br>
>><br>
>><br>
>> On Fri, May 9, 2014 at 11:28 PM, David Majnemer<br>
>> <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>> wrote:<br>
>>><br>
>>> Filing a bug with a reduced test-case would be helpful to get this fixed.<br>
>>><br>
>>><br>
>>> On Fri, May 9, 2014 at 2:25 AM, Hovik Melikyan <<a href="mailto:hovik.melikyan@gmail.com">hovik.melikyan@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Hi David,<br>
>>>><br>
>>>> (I should have made it clear that I do understand there's GNUstep<br>
>>>> (whose GUI is so horrible and 1990-ish that makes me want to switch to<br>
>>>> an entirely different industry altogether :) and I do understand I<br>
>>>> can't use Apple's code unless it's covered by a more or less<br>
>>>> permissive license. Libobjc is APSL so we're fine with that. As for<br>
>>>> the rest, Foundation & Cocoa, there is at least one open source<br>
>>>> implementation named Cocotron that's pretty good but is a bit behind<br>
>>>> in terms of the runtime and language features. One possibility, for<br>
>>>> example, would be to adapt Cocotron to the latest libobjc, that's all.<br>
>>>> But let's forget about higher layers for now.)<br>
>>>><br>
>>>> My point is, theoretically there's nothing that stops clang from<br>
>>>> making Apple's libobjc compile and work on Windows, less exceptions.<br>
>>>> We can wait until clang brings exceptions to Windows, that's fine,<br>
>>>> because exceptions are kind of not critical to F/Cocoa.<br>
>>>><br>
>>>> But weak pointers, I think what I found is a bug. You declare a __weak<br>
>>>> pointer and the compiler treats it as __strong for a particular<br>
>>>> target. The consequences of this bug for an app can be catastrophic.<br>
>>>><br>
>>>> Let's say my setup is a bit unusual, but if there is one little thing<br>
>>>> that possibly needs a little fix, why not? I was hoping to hear some<br>
>>>> ideas as to what I can do: file a bug? suggest a patch? use some<br>
>>>> compiler flag that I didn't know of?<br>
>>>><br>
>>>> --<br>
>>>> H.M.<br>
>>>><br>
>>>><br>
>>>> On Fri, May 9, 2014 at 9:29 AM, David Chisnall<br>
>>>> <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br>
>>>>><br>
>>>>> Hi,<br>
>>>>><br>
>>>>><br>
>>>>> On 8 May 2014, at 23:17, Hovik Melikyan <<a href="mailto:hovik.melikyan@gmail.com">hovik.melikyan@gmail.com</a>><br>
>>>>> wrote:<br>
>>>>><br>
>>>>>> And finally, the GNU compiler is not an option for me because it lags<br>
>>>>>> in some crucial aspects of the ObjC language. I really, really want to<br>
>>>>>> get clang to compile libobjc and then the entire Foundation/Cocoa<br>
>>>>>> emulation layers. Ideally, clang should be able cross-compile this<br>
>>>>>> stuff on OSX.<br>
>>>>><br>
>>>>> You seem to be conflating many parts of the stack.  For all of the<br>
>>>>> stuff<br>
>>>>> that you want, you need:<br>
>>>>><br>
>>>>> - A compiler<br>
>>>>> - An Objective-C runtime<br>
>>>>> - A Foundation / AppKit implementation<br>
>>>>><br>
>>>>> Clang is the compiler, and supports several Objective-C runtimes.  The<br>
>>>>> only supported configurations on Windows, however, are the GNU family<br>
>>>>> of<br>
>>>>> runtimes (the Apple runtime works on Windows, but requires code that<br>
>>>>> Apple<br>
>>>>> has not open sourced to actually be useful).  The GCC and GNUstep<br>
>>>>> runtimes<br>
>>>>> both work on Windows and the GNUstep runtime has supported ARC for<br>
>>>>> several<br>
>>>>> years and is used by a number of commercial products on Windows,<br>
>>>>> Android,<br>
>>>>> and so on.<br>
>>>>><br>
>>>>> Once you have the compiler and runtime, you need a Foundation<br>
>>>>> implementation that supports the runtime.  Again, GNUstep provides this<br>
>>>>> for<br>
>>>>> the GCC and GNUstep runtimes.<br>
>>>>><br>
>>>>> I'm not sure what you mean by 'the entire Foundation/Cocoa emulation<br>
>>>>> layers'.  Foundation and Cocoa are just libraries.  You can not use<br>
>>>>> Apple's<br>
>>>>> implementation on Windows[1], because Apple doesn't license their<br>
>>>>> library<br>
>>>>> implementations for third parties.<br>
>>>>><br>
>>>>> David<br>
>>>>><br>
>>>>> [1] Unless you can find a copy of Yellow Box for Windows, in which case<br>
>>>>> you can but you'll have a *really* old version.<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> cfe-dev mailing list<br>
>>>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>>><br>
>>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
> --<br>
> <a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
> the browser experts<br>
><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>