Re: Universal build of cranky open source lib with a configure script
Re: Universal build of cranky open source lib with a configure script
- Subject: Re: Universal build of cranky open source lib with a configure script
- From: Bill Northcott <email@hidden>
- Date: Sat, 27 Jan 2007 12:12:33 +1100
On 26/01/2007, at 2:21 PM, Bill Bumgarner wrote:
On Jan 25, 2007, at 1:57 PM, John Daniel wrote:
alias uconfigure='env CFLAGS="-isysroot /Developer/SDKs/
MacOSX10.4u.sdk -arch i386 -arch ppc" ./configure --disable-
dependency-tracking'
alias umake='env CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -
arch i386 -arch ppc" make'
I do a uconfigure and then a umake. If it doesn't work perfectly, it
gets me really close.
You may need to update your config script using a recent version of
autoconf, automake, and libtool.
Don't do this.
Doing the above with autoconf based source will not yield a correctly
working universal binary.
It my experience it quite often does.
There are two issues at hand; cross compilation and simultaneously
compiling for two architectures (as per the above recommendation).
Autoconf can support cross compilation, but most projects that use
autoconf do not support cross architecture compilation. Good
projects that don't will actually spew an error and refuse to
configure when targeting something other than the local host's
architecture. Bad projects will merrily configure "correctly" and
then suck up various architecture specific configuration parameters
from the local system's architecture.
The real problem is that passing "-arch i386 -arch ppc" completely
bypasses the per-architecture configuration features of autoconf.
No it does not. As long as the one of the arch options is runnable
on the compiling host the autoconf tests should work just nice and do
wat they are supposed to do. Some one else pointed out the few
pitfalls - endianness etc. Most packages are not concerned about CPU
architecture only the availability of appropriate libraries and tools
and that is what the autoconf tests for.
Autoconf works by testing a bunch of crap on the system, often by
compiling little bits of test code to see if various functions,
features or bugs are present. The results of all these tests are
typically quantified in a bunch of variables and #ifdefs spread across
makefiles and header files.
By specifying '-arch i386 -arch ppc', you are effectively telling the
project to build for two different architectures where both should use
all the configuration from whatever architecture the files happened to
be compiled on!
The end result will be incorrect. The resulting problems may be
obvious or, more likely, they might be incredibly subtle. Depending
on how you are using the compiled product, you might get really lucky
and have something that seems like it works.
Unless the package does something CPU specific there is no reason the
configure output should be incorrect. Hopefully the package has
tests and you should use them.
The main problem I have found is with packages that do maths in C++.
Apple's code does not do this. So subtle C++ maths bugs tend to slip
through into released Apple compilers.
Bill Northcott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden