You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by grady player <gr...@mozy.com> on 2012/02/07 00:50:35 UTC
problem building apr-util 64 bit Mac OS X
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
I have also tried the following:
./configure --build=x86_64 --prefix=`pwd`/64bit --with-apr=`pwd`/../apr-1.4.5 && make all && make install
./configure --build=x86_64 --prefix=`pwd`/64bit --with-apr=`pwd`/../apr-1.4.5 CFLAGS="-m64" && make all && make install
and various other variants, I will track this down if it isn't a known issue, presumably somebody is building a x86_64 version.
to clarify I am looking at the static library, the .a file, not the dynamic library.
Grady Player
gradyp@mozy.com
gplayer@vmware.com
801 548 1371
Re: problem building apr-util 64 bit Mac OS X
Posted by Graham Leggett <mi...@sharp.fm>.
On 07 Feb 2012, at 5:05 PM, grady player wrote:
> libapr-1.a is build 64 bit, libapr_util-1.a is build 32 bit… that alone should count as a bug
In my case, my apr-util is 64 bit, same as apr:
Non-fat file: /tmp/httpd-trunk/lib/libaprutil-1.0.4.2.dylib is architecture: x86_64
Regards,
Graham
--
Re: problem building apr-util 64 bit Mac OS X
Posted by grady player <gr...@mozy.com>.
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
> --
>
Re: problem building apr-util 64 bit Mac OS X
Posted by Graham Leggett <mi...@sharp.fm>.
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
--
Re: problem building apr-util 64 bit Mac OS X
Posted by grady player <gr...@mozy.com>.
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
Grady Player
gradyp@mozy.com
gplayer@vmware.com
801 548 1371
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
>
> Grady Player
> gradyp@mozy.com
> gplayer@vmware.com
> 801 548 1371
>
>
>
>
> On Feb 6, 2012, at 5:51 PM, Graham Leggett wrote:
>
>> On 6 Feb 2012, at 23:50, grady player <gr...@mozy.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.
>>
>> Regards,
>> Graham
>> --
>>
>
Re: problem building apr-util 64 bit Mac OS X
Posted by grady player <gr...@mozy.com>.
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
Grady Player
gradyp@mozy.com
gplayer@vmware.com
801 548 1371
On Feb 6, 2012, at 5:51 PM, Graham Leggett wrote:
> On 6 Feb 2012, at 23:50, grady player <gr...@mozy.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.
>
> Regards,
> Graham
> --
>
Re: problem building apr-util 64 bit Mac OS X
Posted by Graham Leggett <mi...@sharp.fm>.
On 6 Feb 2012, at 23:50, grady player <gr...@mozy.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.
Regards,
Graham
--