I've just downloaded libogg from http://www.xiph.org/downloads/ (http://downloads.xiph.org/releases/ogg/libogg-1.3.0.tar.gz) and I'm now trying to compile the Ogg.xcodeproj project provided in that package. When I try to build, I get the following error:
The run destination My Mac 64-bit is not valid for Running the scheme 'Ogg'.
The scheme 'Ogg' contains no buildables that can be built for the SDKs supported by the run destination My Mac 64-bit. Make sure your targets all specify SDKs that are supported by this version of Xcode.
I get a similar error if I attempt to build the static library instead of the framework:
The run destination My Mac 64-bit is not valid for Running the scheme 'libogg (static)'.
The scheme 'libogg (static)' contains no buildables that can be built for the SDKs supported by the run destination My Mac 64-bit. Make sure your targets all specify SDKs that are supported by this version of Xcode.
Again, this is just opening the project in Xcode 4.3.2 for the first time and attempting to build. I've made no changes to the project file at all.
Can anyone point me in the direction of a solution to get this to compile?
In my case, the Xcode project was linking against an old SDK on an old architecture (OS X 10.5 PPC, whereas I have OS X 10.8 Mountain Lion x64).
To fix this in Xcode 5, select the top-level project in Xcode (the top-most node in the project folder pane, with the blue "A" icon) followed by the Project. Change Architectures to something suitable for your current system, such as Native Architecture of Build machine and change Base SDK to an SDK currently installed in your Xcode environment, such as OS X 10.8.
Here is a screenshot of my project to help you find those settings (following the highlighted parts: kisshelper > kisshelper > Architectures):
Related
X-Code 12, MacoS + M1.
Missing 64-bit support. iOS apps submitted to the App Store must include 64-bit support and be built with the iOS 8 SDK or later. We recommend using the default "Standard Architectures" build setting for "Architectures" in Xcode, to build a single binary with both 32-bit and 64-bit support. With err
enter image description here
Change Build Active Architecture Only to No in Release, Clean Build folder and Archive again:
This will force Xcode to build the 64bit binary regardless of what device is connected.
I have MacOS-X - 10.7 and Xcode - 4.6.2 and made a Mac application. The client side machine is also MacOS-X - 10.7. But in my mac application there was a small error with NSNumberFormatter which when I was changing, Xcode was crashing. So I edited the code in latest Xcode and OSX. And then I made the binary of it and run in MacOS-x - 10.7, its working fine. But the source code is no more opening in Xcode - 4.6.2. Its asking for the latest version of Xcode. My question is will the binary will work fine in older version of OS-X even if it is developed in latest Xcode?
The version of OS X which your application will run on is dictated by the OS X Deployment Target in the project settings. If that is set to support 10.7, then it doesn't matter which version of OS X you built it on: the built application will work on 10.7 and later.
This setting will also set the minimum allowed OS in the Info.plist, so people trying to run the build on earlier OSes will see an alert instead of the app just crashing.
More information on setting the deployment target and building for different OS versions with SDKs is available in the Apple documentation:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html
I'm trying to get objc4-532.2 to work on Mavericks.
(First of all, I tried to compile the latest version of objc4 (objc4-551.1).
This fails due os/lock_private.h is missing (objc-os.h). Maybe anyone knows how to solve this issue?)
Back to topic:
To successfully build objc4-532.2 I need to link against the frameworks which are based
on OS X 10.8.
So I configured the Xcode project to use OS X 10.8 SDKs for Base SDK and OS X Deployment Target.
This works, and I can compile and link a simple console based C program (Xcode template).
However when I try to link this program against Foundation and debug it, it miserably fails with the following error:
dyld: Symbol not found: _objc_debug_taggedpointer_mask Referenced from:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Expected in:
/Users/manu/Library/Developer/Xcode/DerivedData/objc-dtrsexfveobodwdnwlpknyyiekpe/Build/Products/Debug/libobjc.A.dylib
in
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
The symbol _objc_debug_taggedpointer_mask was first introduced in objc4-551.1 (latest runtime) and all 10.9 Frameworks needs to access this symbol (at least in debug mode).
Example:
$ cd /System/Library/Frameworks/Foundation.framework/Versions/C
$ grep objc_debug_taggedpointer_mask Foundation
Binary file Foundation matches
A Framework based on 10.8 doesn't contain such a symbol.
Since my project is configured to use 10.8 SDKs this error should not occur?!
So, what's the missing point?
Thanks!
I solved this problem: the symbol of objc_debug_taggedpointer_mask was imported into runtime after mac os x 10.9, so you need to add the new tags into the 532.2's code to make it compatible with os x 10.9's foundation and other frameworks.
Here is my working directory:
https://github.com/Jeswang/objc4-532.2
(First of all, I tried to compile the latest version of objc4
(objc4-551.1). This fails due os/lock_private.h is missing
(objc-os.h). Maybe anyone knows how to solve this issue?)
The best solution I could find is to manually scrape together the header files as described here:
http://www.mulle-kybernetik.com/weblog/2011/how_to_build_libobjc_for_os_x.html
The closest thing to os/lock_private.h that I have found is private/tsd_private.h from the libpthread project:
https://opensource.apple.com/source/libpthread/libpthread-105.40.1/private/tsd_private.h
Edit
I have also found this:
https://github.com/samdmarshall/OSXPrivateSDK
am using Os X 10.6.4 and X code Version 3.2.3 for developing some simple app files and using PackageMaker to distribute these app files. But when trying to run the package on some other mac I am getting error that the package is not compatible with the Os X its running and file would not be installed. Is this a problem with X code or package maker. sorry for reposting it but although I tried changing base SDK to 10.5, it was getting compiled and ran well on mac I am using for development (Mac OS X 10.6.4) but when installed on mac running OS X 10.5 the .app files were grayed out and message poped up saying 'you cannot use this version of application with this version of Mac'. Any idea why is this happening? Also as mentioned earlier I am using IBOutlet for accepting user date from form and then writing that into a text file. Any idea or solution about it?
Do you have anything set in your Info.plist for the LSMinimumSystemVersion key? This is one place the system looks.
When I was brand new I had trouble figuring this out...
Make sure that your Base SDK and deployment target are 10.5 and that you have the right compiler on(GCG4.0/4.2), also make sure that when you change these settings you change it for both Release and Debug, I once made this mistake of changing it only on debug, and when I built for release it only worked on 10.6 because I didn't change those settings.
I have build an universal binary with xcode 2.4 using sdk10.4 on Mac 10.4.4, when I'm trying to invoke the application in 10.3.9 PPC machine,the application is not getting invoked, saying it is not able to find the libcurl.3.dylib.
Since 10.3.9 has only libcurl.2.dylib the application is not getting invoked?
But according to Universal binary definition, the universal binary build using 10.4sdk should run in the MAC OS prior to 10.4?
What am I missing? Y my application is trying to load libcurl.3.dylib instead of libcurl.2.dylib?
(FYI: In the xcode.proj I'm linking libcurl.dylib, which is the alias name for libcurl
Sorry, but "Universal" means the binary can run on different processors (x86, PowerPC), but it does not mean it can run on earlier versions of Mac OS. This article gives details on building a "Universal" binary that can also run on Mac OS X 10.3.