after a little digging, it looks like the configure script is always adding a -m32 to the CFLAGS section of the rules.mk file (line 44)
this would seem to be a bug to me, but I haven't yet figured out where it is pulling this value from…
apr-1.4.5 seems to work fine
On Feb 7, 2012, at 7:16 AM, 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
801 548 1371
On Feb 6, 2012, at 5:51 PM, Graham Leggett wrote:
On 6 Feb 2012, at 23:50, grady player <email@example.com> wrote:
I am currently building a 32/64 bit version of apr by configuring and building twice and combining the output with lipo, (apr-1.4.5)
I am trying to accomplish the same thing with the 64-bit version with apr-util-1.4.1, but all of my output seems to be i386 32bit,
I am trying to configure and build with the following line:
./configure --target=x86_64 --prefix=`pwd`/64bit --with-apr=`pwd`/../apr-1.4.5 CFLAGS="-m64" && make all && make install
Can you clarify why you're trying to explicitly build for a given architecture?
MacOSX has the concept of a Universal Binary, containing builds for different architectures in the same binary, and both MacOSX and APR support this by default out the box.
In other words, if you try a vanilla build of APR, MacOSX will ensure that all relevant architectures get built, and the right code runs on the right platform.