apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject 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
Date Wed, 14 Oct 2009 12:00:20 GMT

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

Mime
View raw message