I have a Carbon-based project that compiles on XCode 3, but fails on XCode 4.
It can't seem to find any Carbon or QT functions, even though I've included
and #include
I get lots of errors like this:
No member named 'InitCursor' in the global namespace
I tried re-adding in the Carbon.framework from the System/Library/Frameworks folder
The InitCursor function, along with pretty much everything else in QuickDraw, was removed in Lion. You will need to remove your uses of all removed APIs, and probably replace most of them with more modern replacements.
This is a non-trivial task, but it is necessary if you want to build with modern tools and target current and future versions of Mac OS X.
It's been a long time coming, too; QuickDraw has been deprecated for years.
Much of Carbon is still supported, and you should find that you are not getting errors about those APIs.
You mention Qt; I've heard that there is a Cocoa version of Qt now.
Related
I have a serious issue getting Xcode 7.3 to compile a Project against Mac SDK 10.7 with LLVM (7+) and C++11. The source of the issue seems to be Xcode or the fact that I'm running OS X 10.11. Some colleagues of mine don't have the same issue compiling the same issue with older Xcode Versions (6). Here is the general setup:
The needed Libraries and Headers are linked with CMake. The Include paths of everything got checked multiple times. The created Xcode Project also seems to be ok, we've compared all important settings (C++ dialect, std library , target, defines etc) against systems where the project does compile.
The actual error comes when compiling vecLib source.It seems to be a set of random error messages I would trace back to the lack of c++ std headers.. Here are a few examples:
Explicite specialization of non-template class 'complex'
Redifinition of complex as different kind of symbol
Did anybody run into similar problems when working with newer Xcodes against older SDKs?
EDIT
Here is some more informations. After checking what was behind the redifinition, I found that for some odd reason, the complex definition that was interfering with the forward declaration in the file comes from /usr/include/c++/4.2.1. I think that the header is outdated or at least not compatible with c++11. I checked again what the compiler used and the lib / language (std=c++11 and stdlib=libc++) where correctly set. I have the strange feeling that the source in user/include isn't supposed to be included but I don't know how to fix it.
EDIT 2
I've checked the standard include paths with cpp -v and got the following list:
/usr/local/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/bin/../lib/clang/7.3.0/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
The definition of complex in the Xcode toolchain (3rd entry) is the correct one, the definition in /usr/include is the one that seems to be used while compiling, leading to the error messages. The definition of complex uses structs.
What is the issue here? Is the issue that Xcode / Clang or what ever decides to go with usr/include instead of the toolchain include? I've checked the project settings and the compiler output and there was no explicit include of this path.
It seems like AppleClang 7+ and libc++ just doesn't support vecLib from OS X SDK 10.7. I had to go back to Xcode 6 to get it to build.
I'm having trouble linking an Xcode project using the AAF SDK, with Xcode 5.1.1 on MacOS 10.9.5. When I link the main dynamic library, these symbols come up missing:
_StgCreateDocfile
_StgCreateDocfileOnILockBytes
_StgOpenStorage
_StgOpenStorageOnILockBytes
AssertProc
I can't find a definition for them anywhere in the entire source tree for the SDK. The first four appear to be part of Structured Storage on Windows. A Structured Storage library is provided in the SDK and I'm already linking that.
Can anyone tell me of a Mac system library that defines these? Or is there a linker argument that pulls in a library for them? Thanks for any help.
A late answer (!), but in case anyone comes across this... The solution is either:
To use the makefiles with the AAF SDK to generate the AAF dylib,
which works fine. or...
If you use Xcode to build the AAF SDK, ensure the correct
#defines are kept, namely:
_DEBUG OM_DEBUG OM_STACK_TRACE_ON_ASSERT OM_USE_SCHEMASOFT_SS OM_STRUCTURED_STORAGE
Note that DEBUG=1 is absent (it is added by default by Xcode) - if defined, this brings in AssertProc. Define NDEBUG on release builds and omit the debug defines.
The Stg... functions are part of the MS implementation of Structured storage as you stated, but should not be referenced on a Mac, the Schemasoft implementation being used.
I have this in a .h file:
class Ogre::ManualObject;
I don't know how it got there but it's always compiled under multiple compilers - until suddenly XCode5.1 raises it as an error.
Have Apple changed the C++ compiler again?
As John suggested, change class Ogre::ManualObject; to namespace Ogre{ class ManualObject;}. I had exactly the same problem (but with different declarations), also with Ogre and Xcode 5.1. Changed 3 lines, everything worked.
Possibly that never was legal. It would depend on the code around it (hard to say just based on that one line without knowing the referencing points). See this SO thread.
Apparently, you are not the only one experiencing this issue after an XCode 5.1 update. See this thread regarding Scaleform (autodesk.com). I however couldn't find anything related in the XCode or LLVM/clang release notes.
After a marathon coding session, where I added too much code without keeping track of everything, I now have an app that probably has some iOS 5.0 and 5.1 specific enums, calls and frameworks, however, I want my app to support iOSes back to 4.3.
I was hoping that there was an easy way of setting Xcode to compile as if it were compiling for iOS 4.3, so that I would get errors for all of the offending code that needs to be conditioned out, and/or alternatively coded, for older iOS.
I thought I'd get that by using the compiler option:
-D__IPHONE_OS_VERSION_MAX_ALLOWED=__IPHONE_4_3
but that ends up generating error in system header files, not my code.
Given that most enums and frameworks have their availability included in the header files, I have to think that there is an easy way to do what I need.
Has anyone managed to do such a thing without resorting to downloading older Xcodes with old SDKs? There I may run into the issue of Xcodes that won't function properly under Lion (which is what I am running).
UPDATE: It appears as though I can't install Xcode 3.2.6 on Lion. I now will have to find a Snow Leopard Mac, unless I find a way to use compiler options or forcing Xcode to use old SDKs...
Here is a sample of what #mattjgalloway's answer did for me:
Lumin App Group
/Users/mz/Dev/Working/Lumin/Lumin/MyUIScreen.m
'brightness' is deprecated: TOO NEW!
'brightness' is deprecated: TOO NEW!
'brightness' is deprecated: TOO NEW!
'brightness' is deprecated: TOO NEW!
/Users/mz/Dev/Working/Lumin/Lumin/LuminViewController+Share.m
'TWTweetComposeViewController' is deprecated: TOO NEW!
'TWTweetComposeViewController' is deprecated: TOO NEW!
'TWTweetComposeViewController' is deprecated: TOO NEW!
/Users/mz/Dev/Working/Lumin/Lumin/LuminViewController.m
'scrollView' is deprecated: TOO NEW!
'connectionWithMediaType:' is deprecated: TOO NEW!
'connectionWithMediaType:' is deprecated: TOO NEW!
'AVCaptureDeviceSubjectAreaDidChangeNotification' is deprecated: TOO NEW!
'setSubjectAreaChangeMonitoringEnabled:' is deprecated: TOO NEW!
Very nice.
I placed the following in my project's .pch file, and am planning on doing so for all projects:
#if DEBUG
#define __IPHONE_OS_VERSION_SOFT_MAX_REQUIRED __IPHONE_OS_VERSION_MIN_REQUIRED
#import "MJGAvailability.h"
#endif
For any project, I am now automatically watching for SDK issues based on the earliest iOS I am targeting. While there still may be SDK changes I have to worry about, at least I know of most framework additions that are unavailable to an older iOS release.
Take a look at my MJGAvailability.h here on GitHub. Basically it defines the right preprocessor #defines so that newer APIs will look like they're deprecated, so you get a compiler warning. There's some documentation at the top of the file, but basically you just do this in your PCH file:
#define __IPHONE_OS_VERSION_SOFT_MAX_REQUIRED __IPHONE_4_3
#import "MJGAvailability.h"
For if you want to support down to iOS 4.3.
It's certainly not 100% foolproof, but I find it incredibly useful for doing what you're asking.
If you want to suppress a warning because maybe you know that it's OK to use that API (you've surrounded it with a respondsToSelector for example) then you can do something like this:
UINavigationBar *navBar = self.navigationController.navigationBar;
if ([navBar respondsToSelector:#selector(setBackgroundImage:forBarMetrics:)]) {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
[navBar setBackgroundImage:[UIImage imageNamed:#"navbar_bg.png"] forBarMetrics:UIBarMetricsDefault];
#pragma clang diagnostic pop
}
Sorry; completely blew that answer the first time. Let's try this again...
Deployment Target sets the lowest OS version you will work with.
SDK sets the highest OS version you will work with
Between Deployment Target and SDK, you have to conditionally check for APIs. See the SDK Compatibility Guide for details on that.
You probably just want to use the old SDK instead.
The easiest way to use old SDKs with newer versions is to save a copy of the .sdk directory and copy it into the new version when you upgrade.
You can, however, download the old stuff, too. Apple just hides it. Start in the Downloads for Apple Developers. Find the copy of Xcode you want. Download Xcode 4.1 for Snow Leopard; it includes iOS SDK 4.3. You can install it in parallel with Xcode 4.3, but you don't have to. Mount the disk. Open a terminal (it's just easier that way). Go to /Volumes/Xcode/Packages. You'll find all the SDKs there.
You can try installing it directly, and that may or may not work for you. You can also unpack the .pkg and get the files you want. I typically use a program called The Unarchiver. It can unpack just about anything. That'll give you a directory that includes a file called "Payload". If you double-click that, it'll expand (it's just a tar.gz that they don't include the extension on). That will give you the Platforms directory. Copy that into the Platforms directory in your copy of Xcode and you should be golden.
All that said, I once I've gotten the system working pretty well, I usually switch back to compiling with the latest and using deployment target. It makes it easier to collaborate with others who don't have the old SDK. And Apple may or may not reject due to linking with an old SDK. They've done that in the past; I don't know the current situation there (haven't had it come up in a while). But I'd tend to recommend submitting something built against the latest.
I am trying to build and use the ConnectionKit framework in my code, but compiling it is yielding close to 100 errors, and about as many 'deprecated' warnings. Does anyone still use this framework, or is it too out of date? When I load it into XCode, I have to change it's default SDK from 10.4 to 10.7, could this be the source of my problems? And if so, is there a way to get the 10.4 SDK into Xcode 4? All I want to do is incorporate webdav support into my app. Perhaps a precompiled framework would be easier to work with...