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: John Daniel <email@hidden>
- Date: Thu, 25 Jan 2007 20:22:01 -0600
On Jan 25, 2007, at 6:12 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.
Sure it will. If you are worried about it, you might want to test the
program after building.
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.
Autoconf barely works to begin with. Like anything else, it only
works on those platforms where it was developed and tested. The
reason for autoconf is so that projects will compile on Linux where
every single machine has a different configuration. Furthermore, it
discourages people from fixing configure scripts because my efforts
to get a Universal Binary for MacOS X may break half the Linux
platforms along with HP-UX 10.2 and AIX. I much prefer projects that
have a separate makefile for each platform.
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!
You are probably right, but fighting an uphill battle. I got my idea
from the following place:
http://developer.apple.com/technotes/tn2005/tn2137.html
I had to add the architecture settings to the make command as well
because some projects did their linking significantly differently
than the compiling. Autoconf is a very complex system and even those
who use it usually don't understand it. I don't like to mess around
in areas that I don't understand. That is why I propose a non-
invasive solution that works for many configure-based open-source
projects.
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.
It could be incorrect. They could be setting some flag for endian-
ness based on the configure script, or it could be a thousand other
things. You'll just have to test it. Testing is much easier when the
project builds successfully. Get it building. If it is broken, fix
it, and commit your changes. If you really know autoconf, then by all
means try to do it properly. On those projects where I have the
knowledge and time to test, that is exactly what I've done.
John
_______________________________________________
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