On Tue, Oct 20, 2009 at 4:54 PM, Barry Scott <[email protected]> wrote: > > On 20 Oct 2009, at 04:18, Branko Čibej wrote: > >> Barry Scott wrote: >>> >>> I think the problem is that configure is used to find out things that >>> change arch to arch >>> like void * size rather then using preprocessor detection of those >>> things. >> >> I wonder, how do you detect the size of void* with the preprocessor in >> C? The preprocessor doesn't understand sizeof. > > You detect that its a build on mac os x and then use the CPU feature macros > that the compiler defines to choose 4 or 8. You end up writing code like > this: > > #ifdef __APPLE__ > #ifdef __x86_64__ > its Mac intel 64 > #endif > etc... > >> >>> Testings for API functions being present would be arch independent. >> >> That depends, doesn't it? There's no guarantee that you have the same >> external libraries available in several different flavours. > > If you are talking about Mac OS X features then yes you have the same libs > on all arch.
A vendor might provide an interface on a subset of architectures. A vendor might have a architecture-specific bug in an interface used by APR that would result in APR needing to disable its use for the affected architecture build. I wouldn't bet that Apple is in a class by itself with regards to these issues. (I recall that we had to disable the use of some OS feature for 64-bit mode in the past, though not on OS X.) APR-util more obviously uses features that aren't OS features and are packaged by groups with different philosophies. Maybe you only have Oracle/MySQL/whatever client libraries for one architecture.
