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 Bumgarner <email@hidden>
- Date: Thu, 25 Jan 2007 19:20:42 -0800
On Jan 25, 2007, at 6:22 PM, John Daniel wrote:
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.
It will only yield a correct result in semi-rare cases. Exceedingly
simple code is likely to work, but I would only trust code that has a
good set of unit tests (that provide decent coverage).
I have seen many cases where someone doing a universal -- formerly FAT
or MAB -- port of a package swore up and down that it worked just fine
only to discover that it certainly wasn't the case on the "other"
architectures.
In the 15 years that people have been trying to get away with this
shortcut, many more people have been burned than succeeded.
Myself included -- I got away with "-arch m68k -arch i386 -arch hppa -
arch sparc" for about a year before discovering that a good sized
chunk of my user's bugs were fallout from this shortcut.
....
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.
For what it is, autoconf works just fine across dozens of platforms,
Linux being a relative latecomer to the autoconf game. With careful
and judicious use, autoconf does an effective -- note I did not say
great -- job of enabling portability in codebases with a very wide
range of targets.
Autoconf on Mac OS X has been working as well as it does on any other
platform since late in the Panther development cycle.
Fixing configure.in and the rest of the autconf inputs is certainly a
pain in the butt, but it is a viable option for cross platform
development with many teams successfully using it to manage a great
many disparate targeted platforms, ranging from embedded to big iron.
However, autoconf was not designed to build universal binaries. Not
by a long shot. It actually works against universal binaries in that
it really wants to create a compilation environment targeted to a
particular architecture.
Like I said before, autoconf *does* support cross compilation, but
many many projects effectively disable cross compilation due to the
way that they use autoconf.
....
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
That document seriously needs revision. Bug filed (rdar://4956293).
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.
Autoconf: the sendmail.cf of project configuration.
Seriously, though. I fully agree.
What I have done is to convert opensource projects into proper Xcode
projects using the Xcode native build system. This has the advantage
of also leveraging the indexer, code sense, and the like during
development.
This, of course, requires some work. Typically, you need to throw
together the equivalent of a config.h that uses #ifdef to switch
between the various architecture variants.
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.
And if it has unit tests, run 'em across all architectures
*independently of the build*! That is, if you are doing development
on intel, build your Universal binary on Intel, copy the build
environment to PPC and run all the unit tests there.
We used SQLite's unit tests throughout Tiger development to flush out
all kinds of bugs across architectures, filesystems, and the like.
b.bum
_______________________________________________
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