[johnsmith]

Hello,

I'm a software developer which until now mostly worked with Windows platform. With a bit of linux background I'm interested in developing in OS X in future. Mainly my software is written in C and C++.

The software I'm making are libraries for programmers and needs to be linkable with popular compilers. Therefore I'd like to know which popular compilers I should pay attention to.
On Windows it's often nessecary to make multiply libs since compiler vendors use their own fileformat (OMF, COFF, etc.) so I assume it's a similar thing with the Mach-O format and maybe ELF?
I know GCC is availble but what about others like CodeWarrior? Wasn't it a popular compiler in the old days?

How much does OS X rely on Unix? Does it use the standard GNU stuff like glibc, pthreads and whatever is common to use?
I will probably need a pseudo random source. Is /dev/random availble?

This leads to my next question about compatibility. Are all the OS X compatible with each other? Like if I compile my libs (no gui or screen output) under OS X 10.3 will it work under 10.1?

Any other hints are welcome also because right now I'm trying to determine my requirements before I got invest in a new machine.

-- John

[smeger]

The two major formats on OS X are mach-o and CFM. CFM is not used for new development, to the best of my knowlegde, but some older Carbon apps still use it.

Codewarrior can produce CFM apps and is used for development of some Carbon programs. But again, most new development seems to be concentrating on mach-o and Apple's Developer Tools (which use gcc internally).

OS X relies heavily on Unix. All of the various threading implementations, for example, use pthreads internally. /dev/random and /dev/urandom are both available, I believe.

Compatibility can be tough. APIs change, as do ABIs. So generally, the answer is no, but you can always cross-compile to get compatibility with older stuff. Check Apple's docs for more info.

Good luck!

[Rickster]

On Windows it's often nessecary to make multiply libs since compiler vendors use their own fileformat (OMF, COFF, etc.) so I assume it's a similar thing with the Mach-O format and maybe ELF?

OS X has only two binary formats: Mach-O is the primary native format, and PEF/CFM is provided for Carbon backwards compatibility. You'll want Mach-O if you want, say, Unix tools built on OS X to be able to link your library without having to use OS X-specific APIs to load it; it's also the preferred format for Cocoa and newer Carbon development. Use PEF/CFM only if your primary clients will be legacy Carbon apps (CFM Carbon apps can still call into Mach-O libraries, it just takes a bit more work).

I know GCC is availble but what about others like CodeWarrior?

CodeWarrior is still around; see www.metrowerks.com. You'll need CodeWarrior if you want to build PEF/CFM binaries -- Apple's tools don't. CodeWarrior also builds Mach-O now, but only Carbon developers who've been around awhile seem to prefer it.

How much does OS X rely on Unix? Does it use the standard GNU stuff like glibc, pthreads and whatever is common to use?

Um, a lot, I guess. Yes, the standard C libraries and many other common Unix (and cross-platform) libraries are available, including pthreads. For the most part, it's not the GNU versions, so that may lead to a little incompatibility -- but if you can already target *BSD, it's pretty easy to also target Darwin/OS X.

I will probably need a pseudo random source. Is /dev/random availble?

/bin/ls says it's there...

Are all the OS X compatible with each other? Like if I compile my libs (no gui or screen output) under OS X 10.3 will it work under 10.1?

Yes and no. Apple has worked to maintain binary compatibility across all OS X releases, so for the most part, apps and libs built against one release will work on any other... provided they don't link libraries that aren't present on older releases or use newer APIs, etc.

However, the preferred compiler version has changed a couple of times, with incompatible changes to the C++ ABI. So if it's C++ libraries you're working with, you may run into trouble there. If your libs are intended to be statically linked into the client binary or shipped alongside it (like a framework inside an app), this can be easy to get around -- just provide multiple versions of your lib, one built with each compiler, and the client developer can choose the one that matches their build environment.

I'd recommend reading Apple's System Overview document for details on library packaging and binary formats.