Mac OS X Universal builds and APR

[Barry Scott]

I'm the author of pysvn that depends on subversion that depends on APR.

The convient way to build universal binaries on the Mac is to use -
arch. For example
to get a binary that is 32bit and 64bit:

        gcc -arch i386 -arch x86_64

This works so long as the code that is being compile is portable  
between the
arch chosen.

I have found that I cannot build subversion as a Mac OS X Universal  
binary
because of none portable code in apr.h created by configure.

apr.h is configured for 32bit or 64bit and that causes either 32bit or  
64bit to
fail.

Items that would need to handled are:

apr_int64_t aways define as long long on Mac.

APR_SIZEOF_VOIDP would need to be set based on preprocessor symbols.

I'm sure there are more issues that I have not noticed.

Are you aware of these issues?

Do you consider they need fixing?

Barry

[Jim Jagielski]

On Oct 18, 2009, at 11:11 AM, Barry Scott wrote:

> I'm the author of pysvn that depends on subversion that depends on  
> APR.
>
> The convient way to build universal binaries on the Mac is to use -
> arch. For example
> to get a binary that is 32bit and 64bit:
>
> gcc -arch i386 -arch x86_64
>
> This works so long as the code that is being compile is portable  
> between the
> arch chosen.
>
> I have found that I cannot build subversion as a Mac OS X Universal  
> binary
> because of none portable code in apr.h created by configure.
>
> apr.h is configured for 32bit or 64bit and that causes either 32bit  
> or 64bit to
> fail.
>
> Items that would need to handled are:
>
> apr_int64_t aways define as long long on Mac.
>
> APR_SIZEOF_VOIDP would need to be set based on preprocessor symbols.
>
> I'm sure there are more issues that I have not noticed.
>
> Are you aware of these issues?
>
> Do you consider they need fixing?
>
> Barry
>

We are aware of these. A patch to address these have been vetoed.
For the time being, this is the way it is.

[Jeff Trawick]

On Sun, Oct 18, 2009 at 11:58 AM, Jim Jagielski <jim@...> wrote:

>
> On Oct 18, 2009, at 11:11 AM, Barry Scott wrote:
>
>> I'm the author of pysvn that depends on subversion that depends on APR.
>>
>> The convient way to build universal binaries on the Mac is to use -arch.
>> For example
>> to get a binary that is 32bit and 64bit:
>>
>>        gcc -arch i386 -arch x86_64
>>
>> This works so long as the code that is being compile is portable between
>> the
>> arch chosen.
>>
>> I have found that I cannot build subversion as a Mac OS X Universal binary
>> because of none portable code in apr.h created by configure.
>>
>> apr.h is configured for 32bit or 64bit and that causes either 32bit or
>> 64bit to
>> fail.
>>
>> Items that would need to handled are:
>>
>> apr_int64_t aways define as long long on Mac.
>>
>> APR_SIZEOF_VOIDP would need to be set based on preprocessor symbols.
>>
>> I'm sure there are more issues that I have not noticed.
>>
>> Are you aware of these issues?
>>
>> Do you consider they need fixing?

To solve the apr.h issue you can use diff to build a merged version of
apr.h after performing separate 32-bit and 64-bit builds (diff -D
some-symbol 32-bit/apr.h 64-bit/apr.h >merged/apr.h", where
some-symbol is whatever the compiler provides to select between 32-bit
and 64-bit).

I don't think anybody has spelled out explicitly how to run the apr
and apr-util builds and merge all necessary headers and so forth (not
that it is complicated, but it would be useful as a FAQ...).  (In
addition to the apr.h issues you outline, some of the APU_HAVE_foo in
apu.h could differ between 32-bit and 64-bit as well.)

(sticking with just plain Leopard for now ;) )

[Jim Jagielski]

On Oct 18, 2009, at 1:00 PM, Jeff Trawick wrote:

> I don't think anybody has spelled out explicitly how to run the apr
> and apr-util builds and merge all necessary headers and so forth (not
> that it is complicated, but it would be useful as a FAQ...).  (In
> addition to the apr.h issues you outline, some of the APU_HAVE_foo in
> apu.h could differ between 32-bit and 64-bit as well.)
>

Apple has provided the diffs for us... we just don't apply them
(we can't apply the as-is because they assume Darwin, whereas my
patch wrapped them in a DARWIN_10 define to make them generic)...

As anticipated, not addressing this here means that everyone and
their mother will be providing their own hacks to this issue
instead of a single canonical fix... Oh well.

[Jeff Trawick]

On Sun, Oct 18, 2009 at 1:14 PM, Jim Jagielski <jim@...> wrote:

>
> On Oct 18, 2009, at 1:00 PM, Jeff Trawick wrote:
>
>> I don't think anybody has spelled out explicitly how to run the apr
>> and apr-util builds and merge all necessary headers and so forth (not
>> that it is complicated, but it would be useful as a FAQ...).  (In
>> addition to the apr.h issues you outline, some of the APU_HAVE_foo in
>> apu.h could differ between 32-bit and 64-bit as well.)
>>
>
> Apple has provided the diffs for us... we just don't apply them
> (we can't apply the as-is because they assume Darwin, whereas my
> patch wrapped them in a DARWIN_10 define to make them generic)...
>
> As anticipated, not addressing this here means that everyone and
> their mother will be providing their own hacks to this issue
> instead of a single canonical fix... Oh well.

There is no consensus yet on the scope of what has to be addressed
(distinct from whether the project or the packager should address it).
 The discussion in the earlier commit thread needs to be carried to
its conclusion.

[mturk]

On 18/10/09 19:57, Jeff Trawick wrote:
>
> There is no consensus yet on the scope of what has to be addressed
> (distinct from whether the project or the packager should address it).
>   The discussion in the earlier commit thread needs to be carried to
> its conclusion.
>

What about simply making apr.h/apu.h as a stubs
for apr-$CPU.h

eg.

/* apr.h */
#if defined(__i386__)
#include <apr-i386.h>
#elif define(__x86_64__)
#include <apr-x86-64.h>
etc...

Something like that is already done on
lots of platforms to simulate the universal (multiarch) concept


Regard
--
^TM

[Jeff Trawick]

On Mon, Oct 19, 2009 at 2:53 AM, Mladen Turk <mturk@...> wrote:

> On 18/10/09 19:57, Jeff Trawick wrote:
>>
>> There is no consensus yet on the scope of what has to be addressed
>> (distinct from whether the project or the packager should address it).
>>  The discussion in the earlier commit thread needs to be carried to
>> its conclusion.
>>
>
> What about simply making apr.h/apu.h as a stubs
> for apr-$CPU.h
>
> eg.
>
> /* apr.h */
> #if defined(__i386__)
> #include <apr-i386.h>
> #elif define(__x86_64__)
> #include <apr-x86-64.h>
> etc...
>
> Something like that is already done on
> lots of platforms to simulate the universal (multiarch) concept

or similar for SPARC or POWER or z or ... ;)

This issue is already being handled by multiple packagers on multiple
platforms besides Darwin, independent of the fat binary concept.

I guess we could provide a helper script to aid packagers by consolidating

* the list of affected header files (hopefully just apr.h/apu.h by design)
* the exact mechanism, for similar experience across distributions

./helpers/merge_headers.p[ly] __i386__ /bld/32/apr-1.3.x/include/
__x86_64__ /bld/32/apr-1.3.x/include/ /inst/include

Neither of these issues is a big deal, but if packagers were to make
use of this it might save the users of apr a little confusion.  But a
set of general notes to packagers on this and other topics could be
much more valuable than solving the small issue of how to use a single
include directory.

(I don't yet see how we can make a useful contribution on other
aspects of multi-architecture support -- fat binary or multiple
bin/lib/build directories or ....)

[mturk]

On 19/10/09 13:28, Jeff Trawick wrote:

>>
>> What about simply making apr.h/apu.h as a stubs
>> for apr-$CPU.h
>>
>>
>
> (I don't yet see how we can make a useful contribution on other
> aspects of multi-architecture support -- fat binary or multiple
> bin/lib/build directories or ....)
>
>

The bottom line is that for each particular platform we could
end up in only two distinct data models.
Well in theory that can spread to five of them
(LP64,ILP64,LLP64,ILP32,LP32) but AFAICT each platform basically
supports only two distinctive.

Anyhow, APR currently lacks the configure options for at
least specifying data model (using CFLAGS=-m32 && ./configure
is a little bit awkward and nowhere documented)

Resolving that would certainly be one small step helping
packagers to solve some of the multi-arch issues.


Regards
--
^TM

[Jeff Trawick]

On Mon, Oct 19, 2009 at 8:18 AM, Mladen Turk <mturk@...> wrote:

> On 19/10/09 13:28, Jeff Trawick wrote:
>>>
>>> What about simply making apr.h/apu.h as a stubs
>>> for apr-$CPU.h
>>>
>>>
>>
>> (I don't yet see how we can make a useful contribution on other
>> aspects of multi-architecture support -- fat binary or multiple
>> bin/lib/build directories or ....)
>>
>>
>
> The bottom line is that for each particular platform we could
> end up in only two distinct data models.
> Well in theory that can spread to five of them
> (LP64,ILP64,LLP64,ILP32,LP32) but AFAICT each platform basically
> supports only two distinctive.
>
> Anyhow, APR currently lacks the configure options for at
> least specifying data model (using CFLAGS=-m32 && ./configure
> is a little bit awkward and nowhere documented)

BTW, you have to specify the arch option in CC for all the
apr-n-config stuff to work properly.

Documentation of the general requirements would definitely be helpful.
 If that existed, would there be any real value in ordaining a
particular arch compiler flag?  That seems endless and out of scope
anyway.

[mturk]

On 19/10/09 14:43, Jeff Trawick wrote:
>>
>> Anyhow, APR currently lacks the configure options for at
>> least specifying data model (using CFLAGS=-m32&&  ./configure
>> is a little bit awkward and nowhere documented)
>
> BTW, you have to specify the arch option in CC for all the
> apr-n-config stuff to work properly.
>

Right. I meant that one.

> Documentation of the general requirements would definitely be helpful.
>   If that existed, would there be any real value in ordaining a
> particular arch compiler flag?  That seems endless and out of scope
> anyway.
>

Having an out-of-the-box solution would certainly help.

Automatically adding CFLAGS=-m32 or CFLAGS=-m64 by some
configure option is usually all that is needed.
Of course things get complicated with different compilers
Eg, for aCC on HP-UX this has to be CFLAGS=+DD32 or
CFLAGS=+DD64.

As part of my daily job I'm using something similar to
APR's config.layout and put the arch selection options
in that file. Changes to configure are trivial and just
merge those options
eg. ./configure --enable-layout=apr --enable-arch=suncc-32


Regards
--
^TM

[Jeff Trawick]

On Mon, Oct 19, 2009 at 9:17 AM, Mladen Turk <mturk@...> wrote:

> On 19/10/09 14:43, Jeff Trawick wrote:
>>>
>>> Anyhow, APR currently lacks the configure options for at
>>> least specifying data model (using CFLAGS=-m32&&  ./configure
>>> is a little bit awkward and nowhere documented)
>>
>> BTW, you have to specify the arch option in CC for all the
>> apr-n-config stuff to work properly.
>>
>
> Right. I meant that one.
>
>> Documentation of the general requirements would definitely be helpful.
>>  If that existed, would there be any real value in ordaining a
>> particular arch compiler flag?  That seems endless and out of scope
>> anyway.
>>
>
> Having an out-of-the-box solution would certainly help.
>
> Automatically adding CFLAGS=-m32 or CFLAGS=-m64 by some
> configure option is usually all that is needed.
> Of course things get complicated with different compilers
> Eg, for aCC on HP-UX this has to be CFLAGS=+DD32 or
> CFLAGS=+DD64.

Forget about CFLAGS; you don't need to include arch flags in CFLAGS
given that you have to include it in CC.

> As part of my daily job I'm using something similar to
> APR's config.layout and put the arch selection options
> in that file. Changes to configure are trivial and just
> merge those options
> eg. ./configure --enable-layout=apr --enable-arch=suncc-32

Perhaps I'm out in left field, but I anticipate that packagers will
determine the appropriate arch flags based on exactly what hardware
they support, and use that across a number of open source packages.
(Should "foo-32" support any 32-bit foo processor ever made, or just
those that could have been made in the last 10 years, or just those
supported by the level of the OS the packager prereqs, or ???)

[mturk]

On 19/10/09 15:41, Jeff Trawick wrote:
>
> Perhaps I'm out in left field, but I anticipate that packagers will
> determine the appropriate arch flags based on exactly what hardware
> they support, and use that across a number of open source packages.

Sure.

> (Should "foo-32" support any 32-bit foo processor ever made, or just
> those that could have been made in the last 10 years, or just those
> supported by the level of the OS the packager prereqs, or ???)
>

I'm not saying this would satisfy each and every possibility
just like config.layout doesn't. However, we have config.layout
with some of the layouts that might even be different on
the actual platform.
We could have similar thing for arch options, that each
packager could use as a template for the actual or specific
target config. The point is that configure would offer an
infrastructure for easy selection of those options in a same
way one can append <Layout foo> to the config.layout
and use ./configure --enable-layout=foo

Regards
--
^TM

[William A. Rowe Jr.]

Mladen Turk wrote:
>
> Anyhow, APR currently lacks the configure options for at
> least specifying data model (using CFLAGS=-m32 && ./configure
> is a little bit awkward and nowhere documented)
>
> Resolving that would certainly be one small step helping
> packagers to solve some of the multi-arch issues.

Bring this to the attention of the libtool and autoconf crew, it's precisely
what they set out to fix, right?  It sure doesn't seem worthwhile to hack
around such things in our configure schema (and fwiw, that is a problem,
above.  CC="gcc -m32" is much more reliable w.r.t. libtool and autoconf
detection.

Oh - CFLAGS, and -m32 are each thoroughly documented, so that assertion is
rather fud'dish.  Not to mention the fact that some systems need you to change
the compiler or other environmental settings.  This puzzle is a platform
issue for platforms to document [heck, it can vary amoung linux distros].

[mturk]

On 19/10/09 16:37, William A. Rowe, Jr. wrote:

> Mladen Turk wrote:
>>
>> Anyhow, APR currently lacks the configure options for at
>> least specifying data model (using CFLAGS=-m32&&  ./configure
>> is a little bit awkward and nowhere documented)
>>
>> Resolving that would certainly be one small step helping
>> packagers to solve some of the multi-arch issues.
>
> Bring this to the attention of the libtool and autoconf crew, it's precisely
> what they set out to fix, right?  It sure doesn't seem worthwhile to hack
> around such things in our configure schema (and fwiw, that is a problem,
> above.  CC="gcc -m32" is much more reliable w.r.t. libtool and autoconf
> detection.
>

This kind of approach doesn't help a bit.
We are saying: OK, we know how to do it, but we are purists
and don't wish to pollute or code base with something we
think should be part of the toolkit we are using.
Go and complain to them directly instead weening here.

Can scon resolve this? If not it seems to me we
are constantly choosing the wrong tools.


Regards
--
^TM

[Barry Scott]

On 18 Oct 2009, at 18:14, Jim Jagielski wrote:

>
> On Oct 18, 2009, at 1:00 PM, Jeff Trawick wrote:
>
>> I don't think anybody has spelled out explicitly how to run the apr
>> and apr-util builds and merge all necessary headers and so forth (not
>> that it is complicated, but it would be useful as a FAQ...).  (In
>> addition to the apr.h issues you outline, some of the APU_HAVE_foo in
>> apu.h could differ between 32-bit and 64-bit as well.)
>>
>
> Apple has provided the diffs for us... we just don't apply them
> (we can't apply the as-is because they assume Darwin, whereas my
> patch wrapped them in a DARWIN_10 define to make them generic)...
>
> As anticipated, not addressing this here means that everyone and
> their mother will be providing their own hacks to this issue
> instead of a single canonical fix... Oh well.

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.

Testings for API functions being present would be arch independent.

On windows don't you just ship the answers as if configure had run?

Maybe Mac OS X is half way between the linux configure detects  
everything
and the windows configure never run.

Barry

(Hi Jeff, we met on the mod_fcgid list.)

[Branko Cibej]

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.

> Testings for API functions being present would be arch independent.

That depends, doesn't it? There's no guarantee that you have the same
external libraries available in several different flavours.

> On windows don't you just ship the answers as if configure had run?

That's because there's no "configure" tool for Windows. I surely hope
SCons will be able to help here, because the various hacks necessary to
customize the Windows build are not tasty.

-- Brane

[William A. Rowe Jr.]

Mladen Turk wrote:

> On 19/10/09 16:37, William A. Rowe, Jr. wrote:
>> Mladen Turk wrote:
>>>
>>> Anyhow, APR currently lacks the configure options for at
>>> least specifying data model (using CFLAGS=-m32&&  ./configure
>>> is a little bit awkward and nowhere documented)
>>>
>>> Resolving that would certainly be one small step helping
>>> packagers to solve some of the multi-arch issues.
>>
>> Bring this to the attention of the libtool and autoconf crew, it's
>> precisely
>> what they set out to fix, right?  It sure doesn't seem worthwhile to hack
>> around such things in our configure schema (and fwiw, that is a problem,
>> above.  CC="gcc -m32" is much more reliable w.r.t. libtool and autoconf
>> detection.
>>
>
> This kind of approach doesn't help a bit.
> We are saying: OK, we know how to do it, but we are purists
> and don't wish to pollute or code base with something we
> think should be part of the toolkit we are using.
> Go and complain to them directly instead weening here.

I didn't say that.  I said fix it at the origin of the flaw.  And in this sort
of case, that could be a one-off patch here until it is accepted upstream.

But don't fill apr code with hacks around broken autogunk.

Can scons fix this?  Inquiring minds do want to know :)

[Barry Scott]

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...

>
>> Testings for API functions being present would be arch independent.
>
> That depends, doesn't it? There's no guarantee that you have the same
> external libraries available in several different flavours.

If you are talking about Mac OS X features then yes you have the same  
libs
on all arch.

For example if I can build APR as a fat binary
Then I can build subversion as a fat binary
And then I can build pysvn as a fat binary

As an example python can be built for powerpc and intel for both 32 bit
and 64 bit in one go. I don't even need a powerpc Mac expect for testing
the resulting build.

>
>> On windows don't you just ship the answers as if configure had run?
>
> That's because there's no "configure" tool for Windows. I surely hope
> SCons will be able to help here, because the various hacks necessary  
> to
> customize the Windows build are not tasty.

My point is that it can be done without configure running.

Barry

[Jeff Trawick]

On Tue, Oct 20, 2009 at 4:54 PM, Barry Scott <barry@...> 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...
>
>>
>>> Testings for API functions being present would be arch independent.
>>
>> That depends, doesn't it? There's no guarantee that you have the same
>> external libraries available in several different flavours.
>
> If you are talking about Mac OS X features then yes you have the same libs
> on all arch.

A vendor might provide an interface on a subset of architectures.  A
vendor might have a architecture-specific bug in an interface used by
APR that would result in APR needing to disable its use for the
affected architecture build.  I wouldn't bet that Apple is in a class
by itself with regards to these issues.  (I recall that we had to
disable the use of some OS feature for 64-bit mode in the past, though
not on OS X.)

APR-util more obviously uses features that aren't OS features and are
packaged by groups with different philosophies.  Maybe you only have
Oracle/MySQL/whatever client libraries for one architecture.

[Jim Jagielski]

On Oct 19, 2009, at 10:37 AM, William A. Rowe, Jr. wrote:

> Mladen Turk wrote:
>>
>> Anyhow, APR currently lacks the configure options for at
>> least specifying data model (using CFLAGS=-m32 && ./configure
>> is a little bit awkward and nowhere documented)
>>
>> Resolving that would certainly be one small step helping
>> packagers to solve some of the multi-arch issues.
>
> Bring this to the attention of the libtool and autoconf crew, it's  
> precisely
> what they set out to fix, right?

I don't think so. The whole idea is that darwin provides a single
library and executable that bundles multiple architectures; and
so the selection of which to use, in a lib, depends on the compiler
flags passed when building the consumer. So, for example, a long
in this bundled lib is *both* 4 and 8 bytes. Which one that will
be used depends on whether the consumer wants to use one or the
other.

IMO, we either need to wrap these as originally attempted or provide
another layer of abstraction...