apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barry Scott <ba...@barrys-emacs.org>
Subject Re: Mac OS X Universal builds and APR
Date Tue, 27 Oct 2009 23:18:03 GMT

On 24 Oct 2009, at 13:36, Jeff Trawick wrote:

> On Sat, Oct 24, 2009 at 8:16 AM, Barry Scott <barry@barrys- 
> emacs.org> wrote:
>>
>> On 22 Oct 2009, at 20:47, Barry Scott wrote:
>>
>>>
>>> On 20 Oct 2009, at 22:30, Jeff Trawick wrote:
>>>
>>>> On Tue, Oct 20, 2009 at 4:54 PM, Barry Scott <barry@barrys-emacs.org 
>>>> >
>>>> wrote:
>>>>>
>>>>> On 20 Oct 2009, at 04:18, Branko ─îibej wrote:
>>>>>
>>>>>> Barry Scott wrote:
>>>>>>>
>>>>>>> I think the problem is that configure is used to find out  
>>>>>>> things that
>>>>>>> change arch to arch
>>>>>>> like void * size rather then using preprocessor detection of
 
>>>>>>> those
>>>>>>> things.
>>>>>>
>>>>>> I wonder, how do you detect the size of void* with the  
>>>>>> preprocessor in
>>>>>> C? The preprocessor doesn't understand sizeof.
>>>>>
>>>>> You detect that its a build on mac os x and then use the CPU  
>>>>> feature
>>>>> macros
>>>>> that the compiler defines to choose 4 or 8. You end up writing  
>>>>> code like
>>>>> this:
>>>>>
>>>>> #ifdef __APPLE__
>>>>> #ifdef __x86_64__
>>>>> its Mac intel 64
>>>>> #endif
>>>>> etc...
>>
>>
>> I have build subversion and apr twice for i386 and x86_64.
>> Then I'm writting scripts to merge the two trees of build files
>> into a single FAT binary kit with FAT libs and header files.
>>
>> The binary code can be handled this way. But the headers
>> cannot as some are different. I'm going to have to do something
>> like:
>>
>> copy i386 version of apr.h to i386-apr.h
>> copy x86_64 version of apr.h to x86_64.apr.h
>>
>> create a wrapper apr.h
>>
>> #ifdef __LP64__
>> #include "x86_64-apr.h"
>> #else
>> #include "i386-apr.h"
>> #endif
>>
>> Below is details of the diffs I see.
>>
>> Here is a diff between building for i386 and x86_64.
>>
>> diff -u
>> /usr/local/svn-1.6.6-i386-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad- 
>> pad-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad/./include/apr-1/apu.h
>> /usr/local/svn-1.6.6-x86_64-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad- 
>> pad-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad/./include/apr-1/apu.h
>> ---
>> /usr/local/svn-1.6.6-i386-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad- 
>> pad-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad/./include/apr-1/apu.h
>>       2009-10-24 12:54:18.000000000 +0100
>> +++
>> /usr/local/svn-1.6.6-x86_64-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad- 
>> pad-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad/./include/apr-1/apu.h
>>   2009-10-24 12:54:26.000000000 +0100
>> @@ -100,7 +100,7 @@
>>  #define APU_HAVE_SQLITE2       0
>>  #define APU_HAVE_ORACLE        0
>>  #define APU_HAVE_FREETDS       0
>> -#define APU_HAVE_ODBC          0
>> +#define APU_HAVE_ODBC          1
>>
>>  #define APU_HAVE_APR_ICONV     0
>>  #define APU_HAVE_ICONV         1
>>
>> It seems that ODBC is not in both i386 and x86_64.
>
> Just curious: is that Apple-delivered ODBC, that they chose not to
> deliver in both architectures, or some third-party ODBC that configure
> found on your system?

This is going to take a bit of effort to track down.
The libodbc.a is for four arch so both i386 and x86_64 should have  
found it and been happy.
Its not clear to me from the logs while its different.

>
>
>>
>> diff -u
>> /usr/local/svn-1.6.6-i386-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad- 
>> pad-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad/./include/apr-1/apr.h
>> /usr/local/svn-1.6.6-x86_64-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad- 
>> pad-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad/./include/apr-1/apr.h
>> ---
>> /usr/local/svn-1.6.6-i386-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad- 
>> pad-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad/./include/apr-1/apr.h
>>       2009-10-24 12:54:17.000000000 +0100
>> +++
>> /usr/local/svn-1.6.6-x86_64-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad- 
>> pad-pad-pad-pad-pad-pad-pad-pad-pad-pad-pad/./include/apr-1/apr.h
>>   2009-10-24 12:54:25.000000000 +0100
>> @@ -239,7 +239,7 @@
>>  #define APR_HAS_UNICODE_FS        0
>>  #define APR_HAS_PROC_INVOKED      0
>>  #define APR_HAS_USER              1
>> -#define APR_HAS_LARGE_FILES       1
>> +#define APR_HAS_LARGE_FILES       0
>
>>
>> Most of the diff here can be avoided by using stdint.h as far as I  
>> can see.
>> Only one I'm not sure of is APR_HAS_LARGE_FILES. Is that set based on
>> 64bit or not?
>
> APR_HAS_LARGE_FILES unfortunately (?) does not simply mean you can use
> files larger than 2GB.  It effectively means that APR is using LFS
> flags in a 32-bit build to support large files.
>
> You can always use large files in a 64-bit build.
>
> (big shrug on the stdint.h comment)

C99 has a header file inttypes.h that provides all the defines you use  
in APR and more besides.
Its you are happy to assume C99 as a minimum compiler level you can  
code against inttypes.h
and stop figuring out type information in configure. Otherwise I'd  
suggest you find out in configure
if inttypes.h is support and use it if it is available otherwise do  
what you do now.

>
> --/--
>
> I don't know how others feel, but I think a helper script could be
> bundled with APR to combine the multiple builds, and maybe even run
> the two separate builds to start with.  It probably wouldn't be
> completely generic, but might be useful as-is or at least as an
> example to all those APR-on-OS X packagers out there ;)

The problem here you can solve from only APR and APR UTIL.
How will this helper impact on building subversion?

At the moment I configure subversion that configures apr
and apr-util as part of its build.

I welcome anything that will make the situation better,
however I feel that until you are happy to fix the configure
to work with multiple arch it will be of limited help.

You can see the scripts that I'm using to solve this for pysvn.

I use this script to build subversion:

http://guest:guest@pysvn.tigris.org/svn/pysvn/trunk/pysvn/ReleaseEngineering/MacOSX/build-svn.sh

And it uses this script to merge an i386 and x86_64 build tree into a  
universal tree.

http://guest:guest@pysvn.tigris.org/svn/pysvn/trunk/pysvn/ReleaseEngineering/MacOSX/make-universal-from-tree.sh

Notice that I have to wrap any header file that has differences  
between i386 and x86_64.

I'm in the middle of trying to get this all working and would not be  
surpised to find that
I have bugs in these scripts.


Barry



Mime
View raw message