libapr-1.a is build 64 bit, libapr_util-1.a is build 32 bit… that alone should count as a bug


Grady Player
gradyp@mozy.com
gplayer@vmware.com
801 548 1371




On Feb 7, 2012, at 8:02 AM, Graham Leggett wrote:

On 07 Feb 2012, at 4:16 PM, grady player wrote:

The reason is that having the concept of a fat binary (Universal was used to denote PPC/i386 fat) doesn't mean that everything compiled on a modern mac will contain both 32bit and 64 bit code…
in fact apr-util build from configure && make all && make install seems to always build 32 bit code….

this is problematic if you are trying to build a static library that is used to link a 32/64 (fat) application.
the output from lipo:

input file libaprutil-1.a is not a fat file
Non-fat file: libaprutil-1.a is architecture: i386

In my case, it seems to be 64 bit:

Non-fat file: /tmp/httpd-trunk/lib/libapr-1.0.4.5.dylib is architecture: x86_64

Check the effect of the compiler flags you're passing. CFLAGS is in theory set externally to configure.

The Universal Binary concept definitely covers 32/64 bit code, and this scenario is supported by APR. From include/apr.h:

/*
* Darwin 10's default compiler (gcc42) builds for both 64 and
* 32 bit architectures unless specifically told not to.
* In those cases, we need to override types depending on how
* we're being built at compile time.
* NOTE: This is an ugly work-around for Darwin's
* concept of universal binaries, a single package
* (executable, lib, etc...) which contains both 32
* and 64 bit versions. The issue is that if APR is
* built universally, if something else is compiled
* against it, some bit sizes will depend on whether
* it is 32 or 64 bit. This is determined by the __LP64__
* flag. Since we need to support both, we have to
* handle OS X unqiuely.
*/
#ifdef DARWIN_10
...

Is the DARWIN_10 symbol present on your platform?

Regards,
Graham
--