Re: svn commit: r824767 - in /apr/apr/trunk: build/apr_hints.m4 configure.in include/apr.h.in include/apr_os_override.h include/arch/darwin/ include/arch/darwin/apr_darwin_types.h

[Joe Orton]

On Tue, Oct 13, 2009 at 01:58:20PM -0000, Jim Jagielski wrote:

> Author: jim
> Date: Tue Oct 13 13:58:19 2009
> New Revision: 824767
>
> URL: http://svn.apache.org/viewvc?rev=824767&view=rev
> Log:
> More Darwin mojo due to 64 and 32 bit multi-arches. The
> deal is we need to install headers that work both when
> installed and used for both 32 and 64 bit builds, ie:
> at compile time. Uses Apple's own apr.h edits as a guide.

This is nuts, -1.  Set a flag in apr_hints.m4 to force the compiler to
pick a single ABI (whichever is the platform default), or fail and make
the user do that.  A compiler which is building for two completely
different ABIs simultaneously invalidates the results of the configure
script.  You have no way to tell whether any given configure test (now
and in the future) has the same result across both ABIs - you'd have to
check it manually for every single test.

Regards, Joe

[Jim Jagielski]

On Oct 13, 2009, at 11:18 AM, Joe Orton wrote:

> On Tue, Oct 13, 2009 at 01:58:20PM -0000, Jim Jagielski wrote:
>> Author: jim
>> Date: Tue Oct 13 13:58:19 2009
>> New Revision: 824767
>>
>> URL: http://svn.apache.org/viewvc?rev=824767&view=rev
>> Log:
>> More Darwin mojo due to 64 and 32 bit multi-arches. The
>> deal is we need to install headers that work both when
>> installed and used for both 32 and 64 bit builds, ie:
>> at compile time. Uses Apple's own apr.h edits as a guide.
>
> This is nuts, -1.

Reverting... we will just rely on others to fix our brokenness
with not being able to correctly handle Darwin and not even try.

[William A. Rowe Jr.]

Joe Orton wrote:

> On Tue, Oct 13, 2009 at 01:58:20PM -0000, Jim Jagielski wrote:
>> Author: jim
>> Date: Tue Oct 13 13:58:19 2009
>> New Revision: 824767
>>
>> URL: http://svn.apache.org/viewvc?rev=824767&view=rev
>> Log:
>> More Darwin mojo due to 64 and 32 bit multi-arches. The
>> deal is we need to install headers that work both when
>> installed and used for both 32 and 64 bit builds, ie:
>> at compile time. Uses Apple's own apr.h edits as a guide.
>
> This is nuts, -1.  Set a flag in apr_hints.m4 to force the compiler to
> pick a single ABI (whichever is the platform default), or fail and make
> the user do that.  A compiler which is building for two completely
> different ABIs simultaneously invalidates the results of the configure
> script.  You have no way to tell whether any given configure test (now
> and in the future) has the same result across both ABIs - you'd have to
> check it manually for every single test.

Joe; what you fail to realize is that your definition of 'nuts' is precisely
Apple's definition of an ABI (parallel, multiple platform architectures).

Not SXS style assemblies, but a single unified binary with multiple states
depending on the particular architecture (1 of many) being compiled.

[Jim Jagielski]

On Oct 13, 2009, at 8:24 PM, William A. Rowe, Jr. wrote:

> Joe Orton wrote:
>> On Tue, Oct 13, 2009 at 01:58:20PM -0000, Jim Jagielski wrote:
>>> Author: jim
>>> Date: Tue Oct 13 13:58:19 2009
>>> New Revision: 824767
>>>
>>> URL: http://svn.apache.org/viewvc?rev=824767&view=rev
>>> Log:
>>> More Darwin mojo due to 64 and 32 bit multi-arches. The
>>> deal is we need to install headers that work both when
>>> installed and used for both 32 and 64 bit builds, ie:
>>> at compile time. Uses Apple's own apr.h edits as a guide.
>>
>> This is nuts, -1.  Set a flag in apr_hints.m4 to force the compiler  
>> to
>> pick a single ABI (whichever is the platform default), or fail and  
>> make
>> the user do that.  A compiler which is building for two completely
>> different ABIs simultaneously invalidates the results of the  
>> configure
>> script.  You have no way to tell whether any given configure test  
>> (now
>> and in the future) has the same result across both ABIs - you'd  
>> have to
>> check it manually for every single test.
>
> Joe; what you fail to realize is that your definition of 'nuts' is  
> precisely
> Apple's definition of an ABI (parallel, multiple platform  
> architectures).
>
> Not SXS style assemblies, but a single unified binary with multiple  
> states
> depending on the particular architecture (1 of many) being compiled.
>

Yep... but I can't implement anything due to the veto.

[Joe Orton]

On Tue, Oct 13, 2009 at 07:24:55PM -0500, William Rowe wrote:
> Joe; what you fail to realize is that your definition of 'nuts' is precisely
> Apple's definition of an ABI (parallel, multiple platform architectures).

Eh?  The Reality Distortion Field does not extend to the definition of
"ABI".  Apple support multiple platform ABIs and can build executables
which contain multiple chunks of object code, each compiled for a
different ABI/architecture.

If the compiler is doing this by default, the results of the configure
script *cannot* be relied upon to be accurate accross all the ABIs the
compiler is using.  What do you disagree with in that statement?  

This starts at AC_CHECK_SIZEOF and goes all the way to the detection of
e.g. an expat library.  How do you know whether the detected expat is
built for all the ABIs your compiler is building for?  Answer: you
don't, you're guessing, and a configure script for which all the results
are only half true is worse than useless.

Reducing half of our configure-time tests to build-time compiler macro
tests for one platform is not going to be maintainable.  Why is it
useful for Joe Random APR User to be building for more than one ABI in
the first place?  Why the heck would he care?  Just pick a default and
run with it by setting $CC to select an ABI.

Regards, Joe

[Jim Jagielski]

On Oct 14, 2009, at 7:00 AM, Joe Orton wrote:

> On Tue, Oct 13, 2009 at 07:24:55PM -0500, William Rowe wrote:
>> Joe; what you fail to realize is that your definition of 'nuts' is  
>> precisely
>> Apple's definition of an ABI (parallel, multiple platform  
>> architectures).
>
> Eh?  The Reality Distortion Field does not extend to the definition of
> "ABI".  Apple support multiple platform ABIs and can build executables
> which contain multiple chunks of object code, each compiled for a
> different ABI/architecture.
>
> If the compiler is doing this by default, the results of the configure
> script *cannot* be relied upon to be accurate accross all the ABIs the
> compiler is using.  What do you disagree with in that statement?
>
> This starts at AC_CHECK_SIZEOF and goes all the way to the detection  
> of
> e.g. an expat library.  How do you know whether the detected expat is
> built for all the ABIs your compiler is building for?  Answer: you
> don't, you're guessing, and a configure script for which all the  
> results
> are only half true is worse than useless.
>
> Reducing half of our configure-time tests to build-time compiler macro
> tests for one platform is not going to be maintainable.  Why is it
> useful for Joe Random APR User to be building for more than one ABI in
> the first place?  Why the heck would he care?  Just pick a default and
> run with it by setting $CC to select an ABI.
>

If APR is built with i386, and installed, then any apps built for
64 bit will core dump on it. The reverse is true as well.

The default is to build for *both*. And when this is done, then
the bit sizes locked in apr.h may or may not be correct depending
on how you build the app that will be *using* it. The __LP64__
tests in the apr.h (etal) files is to ensure that depending on
how people are building *against an installed APR* will have
the right values. Otherwise, anyone shipping an APR lib must
built it for just 1 architecture and ensure that any consumers
build against just that architecture.

At the very least we should create an APR define that specifies
what bitsize was used when built for DARWIN, so at least consumers
can start testing that ("Oh, I see that apr.h defines APR_DARWIN_32
so that means that the installed APR was built for the -arch i386
arch, so I better not try to build subversion with -arch x86_64").

[Joe Orton]

On Wed, Oct 14, 2009 at 08:00:20AM -0400, Jim Jagielski wrote:
> On Oct 14, 2009, at 7:00 AM, Joe Orton wrote:
>> Reducing half of our configure-time tests to build-time compiler macro
>> tests for one platform is not going to be maintainable.  Why is it
>> useful for Joe Random APR User to be building for more than one ABI in
>> the first place?  Why the heck would he care?  Just pick a default and
>> run with it by setting $CC to select an ABI.
>
> If APR is built with i386, and installed, then any apps built for
> 64 bit will core dump on it. The reverse is true as well.

If APR changes $CC to force a platform ABI choice as I suggested, then
any apps built against APR will be (must be) built using the same $CC,
inherited via `apr-N-config --cc`.  Otherwise all bets are off, as has
always been true.

> The default is to build for *both*. And when this is done, then
> the bit sizes locked in apr.h may or may not be correct depending
> on how you build the app that will be *using* it. The __LP64__
> tests in the apr.h (etal) files is to ensure that depending on
> how people are building *against an installed APR* will have
> the right values. Otherwise, anyone shipping an APR lib must
> built it for just 1 architecture and ensure that any consumers
> build against just that architecture.

Packagers/redistributors can build APR twice (or N times) and merge the
results to get a "fat" binary - this is a problem for Darwin packagers,
not for upstream.  From a 10 second google, this seems to be how Apple
recommend you do it:

http://developer.apple.com/opensource/buildingopensourceuniversal.html

I would not be averse to including (configure --enable-flag conditional)
a solution like the apr-wrapper.h we use in Fedora to allow distribution
of a single arch-independent apr.h which will DTRT on multiple
platforms, if there's wider support for that.  But that wouldn't
distract from the need to build the thing twice and merge the results.

> At the very least we should create an APR define that specifies
> what bitsize was used

APR_SIZEOF_VOIDP?

Regards, Joe