[cfe-dev] Weak pointer support on 32-bit platforms

[Hovik Melikyan]

Apologies, my bad, there is no bug. Turns out in certain circumstances
MinGW can redefine __attribute__ to do nothing, and as a result __weak
becomes either a simple "unsafe" ptr or for certain setups it may
become __strong.

In any case, I decided to go the route of patching clang to accept a
new type of -fobjc-runtime. For the time being the patch will be
internal of course.

--
H.M.


On Fri, May 9, 2014 at 11:28 PM, David Majnemer
<david.majnemer at gmail.com> wrote:
> Filing a bug with a reduced test-case would be helpful to get this fixed.
>
>
> On Fri, May 9, 2014 at 2:25 AM, Hovik Melikyan <hovik.melikyan at gmail.com>
> wrote:
>>
>> Hi David,
>>
>> (I should have made it clear that I do understand there's GNUstep
>> (whose GUI is so horrible and 1990-ish that makes me want to switch to
>> an entirely different industry altogether :) and I do understand I
>> can't use Apple's code unless it's covered by a more or less
>> permissive license. Libobjc is APSL so we're fine with that. As for
>> the rest, Foundation & Cocoa, there is at least one open source
>> implementation named Cocotron that's pretty good but is a bit behind
>> in terms of the runtime and language features. One possibility, for
>> example, would be to adapt Cocotron to the latest libobjc, that's all.
>> But let's forget about higher layers for now.)
>>
>> My point is, theoretically there's nothing that stops clang from
>> making Apple's libobjc compile and work on Windows, less exceptions.
>> We can wait until clang brings exceptions to Windows, that's fine,
>> because exceptions are kind of not critical to F/Cocoa.
>>
>> But weak pointers, I think what I found is a bug. You declare a __weak
>> pointer and the compiler treats it as __strong for a particular
>> target. The consequences of this bug for an app can be catastrophic.
>>
>> Let's say my setup is a bit unusual, but if there is one little thing
>> that possibly needs a little fix, why not? I was hoping to hear some
>> ideas as to what I can do: file a bug? suggest a patch? use some
>> compiler flag that I didn't know of?
>>
>> --
>> H.M.
>>
>>
>> On Fri, May 9, 2014 at 9:29 AM, David Chisnall
>> <David.Chisnall at cl.cam.ac.uk> wrote:
>> > Hi,
>> >
>> >
>> > On 8 May 2014, at 23:17, Hovik Melikyan <hovik.melikyan at gmail.com>
>> > wrote:
>> >
>> >> And finally, the GNU compiler is not an option for me because it lags
>> >> in some crucial aspects of the ObjC language. I really, really want to
>> >> get clang to compile libobjc and then the entire Foundation/Cocoa
>> >> emulation layers. Ideally, clang should be able cross-compile this
>> >> stuff on OSX.
>> >
>> > You seem to be conflating many parts of the stack.  For all of the stuff
>> > that you want, you need:
>> >
>> > - A compiler
>> > - An Objective-C runtime
>> > - A Foundation / AppKit implementation
>> >
>> > Clang is the compiler, and supports several Objective-C runtimes.  The
>> > only supported configurations on Windows, however, are the GNU family of
>> > runtimes (the Apple runtime works on Windows, but requires code that Apple
>> > has not open sourced to actually be useful).  The GCC and GNUstep runtimes
>> > both work on Windows and the GNUstep runtime has supported ARC for several
>> > years and is used by a number of commercial products on Windows, Android,
>> > and so on.
>> >
>> > Once you have the compiler and runtime, you need a Foundation
>> > implementation that supports the runtime.  Again, GNUstep provides this for
>> > the GCC and GNUstep runtimes.
>> >
>> > I'm not sure what you mean by 'the entire Foundation/Cocoa emulation
>> > layers'.  Foundation and Cocoa are just libraries.  You can not use Apple's
>> > implementation on Windows[1], because Apple doesn't license their library
>> > implementations for third parties.
>> >
>> > David
>> >
>> > [1] Unless you can find a copy of Yellow Box for Windows, in which case
>> > you can but you'll have a *really* old version.
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>