You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Aaron Bannert <aa...@codemass.com> on 2007/10/31 01:12:10 UTC

APR on Leopard (works, but has issues)

Hi Everyone, I've been testing our code on Darwin 9/Leopard:

Good news: it works and we can actually create universal binaries:

.libs/libapr-1.0.dylib: Mach-O universal binary with 3 architectures
.libs/libapr-1.0.dylib (for architecture ppc7400):	Mach-O dynamically  
linked shared library ppc
.libs/libapr-1.0.dylib (for architecture i386):	Mach-O dynamically  
linked shared library i386
.libs/libapr-1.0.dylib (for architecture x86_64):	Mach-O 64-bit  
dynamically linked shared library x86_64


Bad news:

1) The autoconf code that selects the int_value and long_value aren't  
consistent for all three architectures (ppc/i386/x86_64). It should be  
choosing long_value="long long" but it's picking "long" instead,  
probably because that would also be correct on my i386/x86_64 machine.  
That'll need to be fixed.

2) The atomics code breaks presumably because the compiler/linker  
tries to link the same asm in all three architectures. Workaround: -- 
enable-nonportable-atomics=no


How did I do it:

./buildconf
CFLAGS="-arch ppc -arch i386 -arch x86_64 -pipe -Wall -g" \
LDFLAGS="-arch ppc -arch i386 -arch x86_64 -pipe" \
./configure --enable-nonportable-atomics=no
make clean
make
make install


I'll poke around in the autoconf code to see if I can fix the  
int_value/long_value selector, but so far I haven't had any  
inspirations. As for the atomics issue I'm not sure how to solve this,  
any ideas?

-aaron

Re: APR on Leopard (works, but has issues)

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Aaron Bannert wrote:
> Hi Everyone, I've been testing our code on Darwin 9/Leopard:
> 
> Good news: it works and we can actually create universal binaries:
> 
> .libs/libapr-1.0.dylib: Mach-O universal binary with 3 architectures
> .libs/libapr-1.0.dylib (for architecture ppc7400):    Mach-O dynamically 
> linked shared library ppc
> .libs/libapr-1.0.dylib (for architecture i386):    Mach-O dynamically 
> linked shared library i386
> .libs/libapr-1.0.dylib (for architecture x86_64):    Mach-O 64-bit 
> dynamically linked shared library x86_64

Funky :)

> Bad news:
> 
> 1) The autoconf code that selects the int_value and long_value aren't 
> consistent for all three architectures (ppc/i386/x86_64). It should be 
> choosing long_value="long long" but it's picking "long" instead, 
> probably because that would also be correct on my i386/x86_64 machine. 
> That'll need to be fixed.

Three architectures, three autoconf's is my gut reaction.  That said, it's
possible we make an apr.hdarwin that determines some of these fields by
compiler-driven flags (not by user controllable flags).  So there would
not be any side effects from the way the user chooses to build, but it
would bend depending on architecture.

I *presume* the compiler physically runs 3x against the very same header
files when compiling a three-platform universal binary?

> 2) The atomics code breaks presumably because the compiler/linker tries 
> to link the same asm in all three architectures. Workaround: 
> --enable-nonportable-atomics=no

Was this after I shifted ppc.c atomics to the end of the file, in order to
attempt to fall in proximity of the relocation stubs?  Perhaps list the
-arch ppc last?

What were the exact error messages?

> How did I do it:
> 
> ./buildconf
> CFLAGS="-arch ppc -arch i386 -arch x86_64 -pipe -Wall -g" \
> LDFLAGS="-arch ppc -arch i386 -arch x86_64 -pipe" \
> ./configure --enable-nonportable-atomics=no
> make clean
> make
> make install

Simple enough.


Re: APR on Leopard (works, but has issues)

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> 
> (FWIW, if you are attempting to vary the compiler ABI choice it should 
> be done by using CC="cc -foo" rather than adding flags to {C,LD}FLAGS)

Just on that point, users could argue that's an attribute of our bogus
autoconf usage ;-)  There's not a lot preventing us from making {C|LD}FLAGS
work 'properly', except for a ton of effort I doubt we have time to both
implement and properly review :)

Re: APR on Leopard (works, but has issues)

Posted by Joe Orton <jo...@redhat.com>.
On Tue, Oct 30, 2007 at 05:12:10PM -0700, Aaron Bannert wrote:
> Bad news:
> 
> 1) The autoconf code that selects the int_value and long_value aren't  
> consistent for all three architectures (ppc/i386/x86_64). It should be  
> choosing long_value="long long" but it's picking "long" instead,  
> probably because that would also be correct on my i386/x86_64 machine.  
> That'll need to be fixed.

How would you expect that to work?  configure will run tests which 
generate a build environment which will be correct for a single 
architecture.  If you want to build an APR development environment for 
three different architectures you're going to end up having to build it 
three times.

(FWIW, if you are attempting to vary the compiler ABI choice it should 
be done by using CC="cc -foo" rather than adding flags to {C,LD}FLAGS)

joe