Irrlicht Engine

There's no way but to compile two different executables, one in each platform. Windows and Mac OS X executable file formats are quite different from each other even when you just compare PCs and Intel Macs, and PowerPC Macs are even more different, as they use a different processor architecture.
And as for cross-compiling, there's no cross-compiler for OS X available yet.

Ok, thanks.
That answered my question.

MikeR wrote:What I want to do is to make one app that can be used on eather mac or windows. One app, 2 platforms. Isn't there a way to set the linker to check the op sys to decide which dll to use? (I think I read that somewhere.)
Something like:
#IFNDEF WIN_32
#DEFINE WIN_32
#pragma comment(lib, "Irrlicht.lib")
endif
else
#pragma comment(lib, Irrmac.lib)

or something like that, where the device chooses which lib to use.

So using compiler directives in this way would remove the part that does not match for the ifdef, so you get either the one lib, or the other, but not both. Using ifdef is the best way to have one source code for lots of different target platforms. But you have to compile it for each architecture.
The binary formats mentioned by ElementoY is a major hurdle to have cross-platform binaries. The code inside binaries is very different for every architecture out there. This include parameter passing and other calling conventions, but also the execution code that is needed first, before the actual app is started. There are some ways to come around such problems, though. For example IBM added Linux executable format support for their AIX systems such that you can run Linux apps without recompiling. Another good example is the use of Win32.dll files under Linux, e.g. for WLAN driver things. But using dlls is still a lot simpler than using complete apps.
Cross compiling would also just produce a binary for one platform, but compilation is done on another platform (which would not be able to execute the produced binary). This is common for embedded systems where the target platform is too limited for the compilation job.
Fat binaries that have been sed with MacOS when changing platforms (from m68k to PPC and now from PPC to ix86) are different in that they use the sme binary format, and only have to produce two versions of the assembler code and merge them together. So the OS knows where to jump into the app on which platform and the correct opcodes are located at that special place. But you need OS support for such binaries.