I am creating a project in maverics(using xcode 5.1.1) ,for 64 bit its running fine but for 34 bit it is giving error.
while running on 34 bit getting this error "-fobjc-arc is not supported on platforms using the legacy runtime"
to remove above error disabled ARC,but i need ARC also
so is there any way to create a project in Maverics using ARC on 32 bit
The 64-bit transition guide for OSX states quite clearly that ARC on OSX is only supported on 64bit.
Applications that target OS X v10.7 and later should take advantage of automatic reference counting (ARC). This technology frees you from having to manually retain and release objects, and in so doing, often fixes latent bugs in applications.
ARC is supported only in the new Objective-C runtime, which is supported only in 64-bit applications. For this reason, most new development should be 64-bit.
Related
I've installed osx 10.10 ( Yosemite ) and since then the device (NI-USB 6210) is not working anymore.
The problem is obviously driver related. I called National Instruments and they confirmed the issue, and they also told me that the problem will be probably fixed in the next release of the nidaqmx, that will happen not so soon.
So their suggestion is to downgrade to Mavericks, which kinda suck.
They also told me to check the compatibility table
http://www.ni.com/labview/os-support/i/
in order to know when if will be supported, until then I have to struggle with downgrade or find a workaround which would be the best thing. anybody found a solution to this problem lately?
Depending on your device and how you program it, you should be able to get it working on Yosemite using NI-DAQmx Base 14.0 [1].
NI-DAQmx Base 14.0 does not claim Yosemite support, but after inspecting the installer and running a few tests, here is what I have determined:
The installer, kernel extensions, frameworks, and applications are signed by National Instruments, which means Gatekeeper won't interrupt you with "are you sure you want to do this?" questions.
Both 32-bit and 64-bit LabVIEW APIs are provided.
Both 32-bit and 64-bit C APIs are provided, but a C or Cocoa application emits a warning on exit. It appears one of the components in the driver attempts to access UI elements from a background thread. My suspicion is that the LabVIEW Run-Time Engine, in which the DAQmx Base C API runs, is doing that.
Links
[1] NI-DAQmx Base 14.0 for Mac
http://www.ni.com/download/ni-daqmx-base-14.0/5060/en/
I had this same problem, and spent an evening figuring out the problem.
Apparently, the NiDaq framework tries to send a message setHandler:withData: to the appdelegate. On yosemite, this handler no longer exists, causing the exception.
If you haven't implemented such message in your own app delegate, things go bad.
But you can simply implement a dummy handler by adding this to your application delegate class :
- (id)setHandler:(id)a withData:(id) b
{
return nil;
}
this way, the framework doesn't crash !!! I still have to test if the measured data is correct, but at least i'm running again !
The Carbon framework will soon be deprecated in the near future.
My first question is whether the deprecation is targeted towards a particular release i.e. whether it's incompatible with 64-bit machines?
Also, since it is known to be deprecated, we are working towards removing the Carbon dependencies and using Cocoa framework instead. While removing some, I came across the use of EventRecord struct defined in the Events.h file. What should be the Cocoa equivalent of the above struct i.e. I should be able to loop through the Event records while using cocoa too.
Carbon does work with 64-bit machines, but it doesn’t work in a 64-bit mode, it works in 32-bit mode. You definitely want off it.
Cocoa has NSEvents (NSEvent.h), but a lot of what EventRecord appears to cover just isn’t relevant in Cocoa. Like, you don’t have to worry about “this portion of the window was uncovered” events—the system just calls “-drawRect:” on your NSView subclass.
So I'm trying to use AFNetworking library for REST services on a project I want to build on my 2006 Macbook. The Macbook is a first-gen 2006 32-bit Core Duo w/ snow leopard.
I'm fairly new to Objective-C development and I'm following the tutorial to get started with AFNetworking here: https://github.com/AFNetworking/AFNetworking/wiki/Getting-Started-with-AFNetworking
Using xcode 4.2 my problem is that right away when I create a new project and try and build I get: Semantic Issue - Synthesized property 'window' must either be named the same as a compatible ivar or must explicitly name ivar.
I checked the Build Settings of my new project and for some reason xcode by default assumes 64-bit Intel architecture when my machine is 32bit?! weird. I swapped it to 32-bit and this is where the error came up.
So I can correct this Semantic Issue now by explicitly creating my own window instance var in AppDelegate via:
NSWindow * _window;
I read about this on building out for 32bit objc:
Synthesizing a property without instance variables which seems VERY common (lack of ivar declarations) in lots of public github project code I see. Is everyone forcing 64-bit on us now or just too lazy to create the instance vars? :(
So my problem is that it looks like AFNetworking library was built out for 64-bit Intel because when I add AFNetworking to my project I get the same Semantic Issue ivar errors all over the place. Looking at the library code there are no explicit instance variables declared throughout the code for any properties.
Am I completely screwed here? I could fix this situation by manually creating instance vars for all the properties but this would be such a pain for long-term project maintenance.
I guess what I'm wishing here is that there was some sort of compiler flag that I could add that would fix this all in one-shot?? but I'm guessing that I'm out of luck and it's simply time to trash this Macbook and pickup a new modern one.
Automatically synthesized instance variables require the "modern" Objective-C runtime which is only available on 64-bit machines. So, unfortunately you are correct that you can't just set a compiler flag to fix this. The solution is indeed to add instance variable declarations for the properties in the class(es) you're trying to use.
I'm not sure that's so difficult that it's worth throwing out your computer... That said, the conveniences offered by the modern runtime are pretty tempting to developers, and you're not likely to see a lot of new code going forward that maintains support for 32-bit Macs. Apple only sold 32-bit Intel Macs for a short time, and Lion requires a 64-bit Mac, so the proportion of people using 32-bit Macs is already quite small, and rapidly getting smaller.
What is the technical reason for ARC to be supported by iOS 4.0 and above only?
It is my understanding that it is a compiler feature, which merely inserts memory management related code automatically instead of requiring the developer to do so. From what I read the calls themselves remain the same - at least that's what Apples Transitioning to ARC Guide implies.
As such, it should not involve features that have not been present in previous versions of iOS, and indeed ARC does work with iOS 4.0 despite having been introduced later.
I'm asking this question out of curiosity and don't actually need to make ARC work with iOS 3.x.
It is for the same reason that automatic reference counting only supports 64-bit Snow Leopard as a minimum deployment target: ARC support requires certain features present only in a new enough version of the modern runtime. That modern runtime was introduced with iOS 4.0, so older iOS versions lack the runtime capable of handling some of the things required technically by ARC. If it were just keyed to OS versions, 32-bit Snow Leopard applications would be supported as well, but only the 64-bit runtime is the modern one there.
If you watch Apple's presentations from WWDC 2011, particularly the "Objective-C Advancements In-Depth," you'll see that a number of under-the-hood improvements have been made to speed up the retain / release process, as well as things like the faster #autoreleasepool. There's an entire section on runtime support in the LLVM ARC specification. These improvements require more than just compiler support.
We already had to use the modern runtime for features like automatic synthesis of instance variables (as explained in Apple's documentation), so this isn't a terrible surprise.
Even iOS 4.0 as a target lacks support for weak references, so there are clearly technical issues at play here. This isn't just a marketing strategy to drive developers to the newer versions, as has been asserted by others.
The docs of Apple states that the dealloc chaining to super is handled in runtime in the case of ARC.
The kind of a same question would be:
Why is NSRegularExpression only supported by iOS 4.0+ and Mac OS X 10.7(Lion)+?
You have fully working simulators of iOS 5.0(and 4.0 obviously) in Mac OS X 10.6.7(Snow Leopard) where you can easily use NSRegularExpression, but it's not supported by Mac OS X 10.6.7 itself.
And concerning your question: ARC was introduced with iOS 5.0. At that time there were not many iOS 3.x users anymore, so my opinion is that Apple was a bit too lazy to make ARC compatible with iOS 3.x.
My guess would be that the clang tool chain (required for ARC) does not build binaries compatible with iOS 3.x.
Also, there are a couple of C functions used in place of sending -retain and -release that might not be available in iOS 3.x
http://www.informit.com/articles/article.aspx?p=1745876
This may be subjective but, if I'm writing some code in Objective-C 2.0 and I'm writing about it on, for example, Twitter or in a blog, then should I refer to it as Objective-C 2.0 or just Objective-C?
The answer is actually not so subtle. Objective-C 2.0 was a sort of moniker used to identify the version of Objective-C that was released a couple of years ago at WWDC.
However, there are actually several different things that could be construed as Objective-C 2.0.
There is the API, the ABI, architecture, and platform.
Across all of the three, Objective-C 2.0 can refer to the specific set of syntactic features available and it is [almost] completely the same across all platforms and architectures. The one difference is synthesized ivars; only available on 64 bit Mac OS X and iPhone (but not in the simulator).
The ABI -- or Application Binary Interface -- refers to something slightly different; the way stuff is laid out in memory and how exceptions are handled. Exceptions are actually different between 32 bit Mac OS X, 64 bit Mac OS X, and iPhone. 32 bit Mac OS X has very expensive exception setup, but cheap throws. 64 bit Mac OS X has very cheap exception setup and slightly more expensive throws (and they are C++ compatible). iPhone has C++ compatible exceptions, but not quite as cheap setup.
Then there is the architecture; there are subtle differences between the variants of Intel, PPC, and arm CPUs.
Finally, platform; there are additional differences -- mostly subtle, the larger quantified by the above descriptions -- between the platforms.
So, Objective-C 2.0 doesn't really mean much. It is just Objective-C and the subtleties of the language are determined by the target platform, architecture, and operating system version. As well, the release of the Xcode toolchain can impact compilation in that certain bugs may be fixed that might allow additional features to be used in additional circumstances.
So, no, really.... just use Objective-C.
Unless what you are writing about is specific to the 2.0 version of the language, use just Objective-C.
With regards to stack overflow specifically, prefer objective-c to objective-c-2.0 because few people follow the objective-c-2.0 tag
Use Objective-C 2.0. Although you do not have to, its clearer. Its so people know you are talking about 2.0.