Universal headers?

[Skorche]

How are you supposed to deal with libraries that generate different headers for the ppc and intel versions?

I noticed that the Ogg library uses different types in it's headers.This makes me wonder if there are any other libraries that I'm already using that have header issues that I don't even know about.

[akb825]

You could always use a #ifdef to differentiate between them. (this is assuming they don't already use #ifdefs in their headers) I'm not sure exactly what is used for each platform, but I'm sure it wouldn't be too difficult to find.

[Skorche]

I thought of that but after Googling for 10 minutes I still couldn't find a list of #defines for processor type.

[AnotherJake]

You could try __i386__ and __ppc__

[DoG]

__ppc__ (and __POWERPC__) and __i386__ should be defined, as well as __BIG_ENDIAN__ and __LITTLE_ENDIAN__, respectively.

[AnotherJake]

I seem to recall reading somewhere in Apple's docs that if you are looking for what byte ordering the architecture uses you should always use __LITTLE_ENDIAN__ and __BIG_ENDIAN__ and not __i386__ and __ppc__ . But if you are only looking for the architecture then __i386__ and __ppc__ would be appropriate.

I also remember a while back, OSC gave me a tip for finding some cmacros and objcmacros from the terminal:

touch foo.h
gcc -dM -E foo.h > cmacros.txt
gcc -dM -E -xobjective-c foo.h > objcmacros.txt

There are a lot of interesting macros to be found in them. I don't know of any official place to find defined macros, but I've found that trick helpful on a few occasions.

[Hog]

the correct syntax for endianness for gcc seems to be

#if BYTE_ORDER == BIG_ENDIAN
...


and LITTLE_ENDIAN without the underscores. This seems to work under
macosx and linux without any prefix headers. Strangely this does not seem to work on some peoples sources that come with xcode project files (infact sometimes theres no syntax that works at all and it seems the project files are royally screwed up), but if you make a new project and add all the files it works fine.

[AnotherJake]

Those are how it's defined in endian.h. You can also do it from defined macros:

#if defined(__BIG_ENDIAN__)
printf("using big endian code");
#endif

#if defined(__LITTLE_ENDIAN__)
printf("using little endian code");
#endif

[OneSadCookie]

If you're using Xcode 2.2, it has architecture-dependent CFLAGS, so you can pass different include paths to the PowerPC and Intel compilations, and get the different headers that way. If you're trying to build UBs without Xcode 2.2, you should upgrade :) If you're building on the command-line, you of course have the same flexibility.

[Hog]

i've looked at the libogg source again and there seem to be no compiler flags whatsoever indicating endianness or processor type (only primitive type definitions for different compilers).

[AnotherJake]

>i've looked at the libogg source again and there seem to be no compiler flags whatsoever indicating endianness or processor type (only primitive type definitions for different compilers).

The ones we're talking about are defined by the compiler. I don't know where to find them except by using the tip that I mentioned above, from OSC.

[Skorche]

If you're using Xcode 2.2, it has architecture-dependent CFLAGS, so you can pass different include paths to the PowerPC and Intel compilations, and get the different headers that way. If you're trying to build UBs without Xcode 2.2, you should upgrade :) If you're building on the command-line, you of course have the same flexibility.

I've looked at this a little bit, but I can't seem to get it right.

If I add the paths directories to OTHER_CFLAGS_ppc and OTHER_LDFLAGS_ppc, with the cross-dev SDK set to "Current MacOS" it compiles fine. However, if I set the cross dev SDK to anything else, it fails. I'm not even compiling for i386.

edit: Looking through the build script, it doesn't even add the flags in that case. Gah!

[OneSadCookie]

Maybe you need to set the SDK per architecture too, rather than setting the global one?

[Skorche]

Maybe you need to set the SDK per architecture too, rather than setting the global one?

I could try that I guess. I was hoping to get 10.2/Intel binary eventually anyway.

Edit: Ok, GCC is outsmarting me again. The ppc build is only working because it is finding the headers in /usr/local/include. Looking at the build log, "setenv OTHER_CFLAGS_arch" is run after the compilation is done! What in the world?

[Skorche]

So how are other people making this work then? Using the same headers for both and hoping that it doesn't cause crashes?

[OneSadCookie]

not using Xcode ;)

[Skorche]

not using Xcode ;)

After searching Apple's documentation and Googling for a while, I decided that this just might be the case.

Having blundered around with make in the past with little success, I gave rake (http://rake.rubyforge.org/) (a Ruby based build tool) a try. Within a couple hours I had learned enough to create a rakefile that could build my project for OS X and Linux. Not bad.