apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: problem building apr-util 64 bit Mac OS X
Date Tue, 07 Feb 2012 15:02:49 GMT
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
--


Mime
View raw message