apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Mac OS X Universal builds and APR
Date Tue, 20 Oct 2009 21:30:47 GMT
On Tue, Oct 20, 2009 at 4:54 PM, Barry Scott <barry@barrys-emacs.org> 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.

Mime
View raw message