I'm currently developing a driver in osx and i'm having problem using XNU files in my Xcode project. I built XNU according to the instructions here:
http://shantonu.blogspot.co.il/2013/10/building-xnu-for-os-x-109-mavericks.html
It successfully builds.
Should I install it in a specific directory for XCODE to find the library and header files?
thanks.
For developing kernel extensions to use with regular OSX kernels, you shouldn't be using a self-compiled kernel, but use the Kernel.framework that Apple supplies with Xcode and the bundled OS X SDK. If you're using Xcode for your build process anyway, the easiest way is to use one of the kext target templates (I/O Kit driver or generic kext) to set up the build system and include the kernel.framework.
If you have an existing Xcode project to which you want to add a kext build, open it and create a new target, then choose one of the kext templates under "system plugin". You get the same choice when you create a new project altogether.
As for choosing between the two templates:
Generic kext is mainly useful if your userspace application will explicitly load the kext.
I/O kit kexts can be loaded automatically on device hotplug or on system boot, so they are usually the most useful if your kext doesn't have some kind of userspace trigger.
Related
In MacOS X there are Mach kernel headers located both at
/usr/include/mach and
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/mach
These headers do not match: they provide different APIs (functions, types, etc).
What is the difference between them?
When should I use which?
From Apple's documentation for the Kernel framework:
The Kernel Framework provides the APIs and support for kernel-resident device drivers and other kernel extensions.
If that's not what you're programming, then you shouldn't use it (including header files from it).
What is the difference between them:
Firstly a bit of context to the usr folder:
/usr
Contains non-essential command-line binaries, libraries, header files, and other data that are not system critical (meaning the system can reboot without needing these files). This folder is a UNIX-specific directory which has been inherited by OS X.
/usr/include
The directory for 'header files' needed for compiling user space source code.
Type man hier in terminal, this will provide you with file system hierachy and a description for each directory.
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
The more recent versions of Xcode don’t use headers from "/usr/include/" anymore. Instead Xcode uses the headers from the SDKs embed in it's package.
Why are they different?
This is because they are almost certainly different versions, both came from different installation sources so the chances that they will be the same is highly unlikely.
When should I use which?
This answer does depend what you're trying to do?
You should use the Xcode package SDKs if you are developing in Xcode, otherwise use /usr/include/ if you're developing outside of Xcode.
Sources:
Linux Exploring the File System
Linux Filesystem Hierarchy
Apple File System Basics
I have an application in the Mac App Store. I'm trying to support users going back to Snow Leopard but this is becoming increasingly difficult.
Recently I've hit a roadblock due to the iTunesLibrary.framework, this framework must be linked to the main executable and yet doing so will always trigger a crash on load when running in Snow Leopard.
To workaround this problem, I want to compile a version of my app that doesn't use features and frameworks from newer versions of OSX. The problem is, how can I launch the compatibility build automatically?
I'm considering trying to make the main executable point to a shell script, but I don't really like that idea. I've also thought of the main executable being a helper that simply launches the full app and then exits. I expect this would work, but I worry about it getting approved by Apple. Finally, I'm wondering if the app bundle format itself can support this kind of setup, maybe via an advanced used of CFBundleExecutable that I'm unaware of.
Has anyone been down this road, what would you suggest?
Try weak linking the frameworks, more information about Weak Linking and Apple Frameworks here. Then also check in your code for the OS version or - (BOOL)respondsToSelector:(SEL)aSelector of any NSObject to determine what you can call and what not.
To have Snow Leopard as Base SDK you'll need an old Xcode and will have troubles submitting to Mac App Store.
Is it possible to develop cross-platform application on Windows and can also compile for Mac OS X from Windows? I have checked Qt but that requires one to compile from Mac using Xcode.
If this is your priority then one option would be Java as at least a jar file built on one platform can be run on another.
If however you're talking about C or C++...
If you are creating a small command line tool then you might be able to make this work with gcc and a cross compiler, but I think it would be a lot of work.
If however you are wanting to create a GUI application I would urge you to give up now. There are so many issues - you'd have to use Carbon or Cocoa APIs which you can't build for on any other platform, you'd have to link against frameworks which won't exist on your compilation host, you won't be able to easily generate .plist files. Qt won't help as you need to be able to build it, which relies on these same frameworks.
In short, there's no alternative to building on an actual mac.
Furthermore, when it comes to fixing bugs, you will absolutely have to do this on a mac (either physical or virtual).
From what I know , in general you do need a mac to make the executable , even for a simple ansi c program you need gcc for mac.
You can create MacPorts Portfile.(If your application is open source)
A MacPorts port is a set of specifications contained in a Portfile
that defines an application, its characteristics, and any files or
special instructions required to install it. This allows you to use a
single command to tell MacPorts to automatically download, compile,
and install applications and libraries.
Take a look at IMCROSS.
IMCROSS is a simple, scripted method of installing cross-compilers and
cross-compiled libraries on a Linux (or possibly other *nix) system,
so that you can develop programs targeted to run on Microsoft Windows
and Mac OS X at the same time and in the same environment as you
develop Linux versions of those programs.
You can certainly do this using Real Studio. It can create Mac OS X applications on Windows without any trouble.
It cross-compiles for Windows, OS X and Linux. And it does it from any platform. It also can create web apps.
Sounds like you should check it out.
I have requirement to create cocoa framework/Libarary in Xcode 4 and support it on 10.3.9.I know it was 10 years older mac.But It is the requirement.
I have gone through the apple's sdk compatibility guide,document was saying that if we set the deployment target to 10.4,unconditionally it will work on 10.3.9 version.I did not understand what is "unconditionally" refers here.
If I need to be supported on 10.3.9,What precautions I need to be taken.Any help would be appreciated.
If your version of Xcode doesn't have a 10.3 SDK, then it will be very hard for you to avoid accidentally using APIs and features which aren't available on 10.3.9. Setting the deployment target makes it so that your program may load on 10.3.9 – the executable won't use dynamic loader commands which are unknown to the loader on 10.3.9 and any references to symbols that aren't available on 10.3.9 will be weak references – but it doesn't mean it will run.
In order to run without crashing, you have to avoid actually dereferencing any of those weak-linked symbols or calling any unavailable methods. The only reliable way to avoid that is to get the compiler's help, but that's only possible if you have the appropriate SDK, which isn't available in Xcode 4. (Honestly, I don't know when a 10.3 SDK was last available.)
Finally, it is folly to try to support a deployment target if you can't test on that platform. You need a machine running 10.3.9. If you have that, then you can use the version of Xcode native to that version of the OS. You can have a code base that can be built in either environment using conditional compilation, although the Xcode project files themselves aren't compatible.
My app needs to run on 10.4 or later. If I launch it on 10.3 it just fails to launch or crashes.
How do you tactfully enforce minimum system requirements? Can you customize the message it shows?
Add a key to your applications Info.plist, specifying LSMinimumSystemVersion as 10.4.X for whatever X you need as a minor version. For more, see Apple's documentation.
I have not used either of these techniques/advice, just passing along the information I have gathered.
You might try something like the SystemVersionCheck “shim” executable to provide a working OS version check for versions that do not honor LSMinimumSystemVersion (e.g. 10.3).
The pre-compiled executable is PPC-only. You might need to rebuild it to support PPC and Intel machines so that it works with 10.3, but also so that 10.6 users are not prompted to needlessly install Rosetta. I found a blog entry that has a hint on how to setup the PPC build to target 10.3 and the Intel build to target 10.4u (it was written about 10.5 and Xcode 3.0 though—do the latest versions of Xcode even include the 10.3 SDK?).
If you experience a crash after adding the LSMinimumSystemVersion key to your app's plist manually, then this is due to the Finder not recognizing the changed state of the app properly. Either restart the Finder (e.g. log out) or duplicate the app in the Finder. The copy will then behave correctly.