apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.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:41:50 GMT
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:


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


Regards, Joe

View raw message