libapr-1.a is build 64 bit, libapr_util-1.a is build 32 bit… that alone should count as a bug
Grady Player [email protected] [email protected] 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 > -- >
