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 --
smime.p7s
Description: S/MIME cryptographic signature
