[Box Backup] Building Box Backup as Universal Binaries [OS X]
boxbackup at fluffy.co.uk
Wed Oct 4 20:25:50 BST 2006
On Wed, 2006-10-04 at 13:30 +0200, patrick machielse wrote:
> Hmm, that would be a bit inconvenient, but if there is no other way I
> guess I'll have to. The curious thing is that my ppc binary breaks
> when I include the -arch i386 flag. I can't really explain why that
> would happen. I get a fully functioning ppc binary when I use:
> export CXXFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc"
> export LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch
> The inclusion of the -arch i386 shouldn't impact the ppc binary when
> I'm building on a ppc machine, if I understand the process correctly.
A standard autoconf check determines endianness. It attempts to
determine it from the header files if possible, else does a runtime
check. The CXXFLAGS will most likely be passed to gcc when the configure
check is run and if it then builds it as per i386 you'll get back the
wrong result (assuming it is using compile time detection with the
headers). You should see the effects in config.log.
Either way the result cannot be right for both so something will break.
I have to say the whole concept of building for two architectures into
one object file simultaneously is rather novel. Which is the problem,
because of course no-one who wrote the tools would have seen that
I don't know much about Mac OS X but theoretically this could affect a
lot more than just the endianness, there's a load of architecture
configure checks including datatype sizes etc.
> Usually, when the configure script produces a config.h file, I can
> modify that file using compiler variables and handle endian issues
> correctly for both architectures:
This unfortunately is Mac specific, and hence not portable. If you can
make this dual build thing work without any nasty hacks the drop the
patch into trac and we'll take a look.
More information about the Boxbackup