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

Mon May 12 12:18:18 PDT 2014

On Mon, May 12, 2014 at 7:20 PM, Reid Kleckner <rnk at google.com> wrote:
>
> You can probably work around this with -D__GNUC__=4.
>
> However, why do you need -fms-compatibility if you are using MinGW?
>

Clang puts itself into MS compatibility mode when the target is e.g.
i686-pc-win32. A better workaround for me was to use
-fno-ms-compatibility.

In any case, I don't think this

    Builder.defineMacro("__weak", "__attribute__((objc_ownership(weak)))");

was a good idea, as it makes some of the most critical attributes in
Objective C dependent on a compiler extension (__attribute__) which is
not always available at compile time!

--
H.M.

On Mon, May 12, 2014 at 7:20 PM, Reid Kleckner <rnk at google.com> wrote:
> On Sun, May 11, 2014 at 4:59 PM, Hovik Melikyan <hovik.melikyan at gmail.com>
> wrote:
>>
>> Hi Alp,
>>
>> On Mon, May 12, 2014 at 12:37 AM, Alp Toker <alp at nuanti.com> wrote:
>> >
>> > The documentation describes __autoreleasing, __strong and __weak as
>> > attribute spellings but the implementation provides them as preprocessor
>> > macro definitions.
>> >
>>
>> Actually no, the documentation says: "The names of the ownership
>> qualifiers are reserved for the implementation. A program may not
>> assume that they are or are not implemented with macros, or what those
>> macros expand to."
>>
>> http://clang.llvm.org/docs/AutomaticReferenceCounting.html#spelling
>>
>> This may lead to unpleasant surprises though, like with MinGW. More
>> specifically, when clang is in -fms-compatibility mode it doesn't
>> define __GNUC__ and that in turn makes MinGW think __attribute__ and
>> some other things should be masked.
>
>
> You can probably work around this with -D__GNUC__=4.
>
> However, why do you need -fms-compatibility if you are using MinGW?
>
>>
>> So the source of confusion here might be that __attribute__ is a "GNU
>> thing" (correct?), at the same time __weak is not, but relies on it.
>>
>> --
>> H.M.
>>
>>
>> On Mon, May 12, 2014 at 12:37 AM, Alp Toker <alp at nuanti.com> wrote:
>> >
>> > On 12/05/2014 02:12, Hovik Melikyan wrote:
>> >>
>> >> 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.
>> >
>> >
>> > Hi Hovik,
>> >
>> > If that's the case there's still a bug in clang:
>> >
>> > The documentation describes __autoreleasing, __strong and __weak as
>> > attribute spellings but the implementation provides them as preprocessor
>> > macro definitions.
>> >
>> > I haven't examined why this is the case but one of the two could do with
>> > fixing (probably the implementation given that this is causing trouble
>> > on a
>> > supported platform). Aaron, any idea what's happened here?
>> >
>> > Alp.
>> >
>> >
>> >
>> >
>> >>
>> >> 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
>> >>>
>> >>>
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> cfe-dev at cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >
>> >
>> > --
>> > http://www.nuanti.com
>> > the browser experts
>> >
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>