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: Fri, 26 Jan 2007 20:57:01 -0800
This thread has gone on long enough. No new ground is being
covered. If you want to follow-up on this, feel free to do so with
me directly.
On Jan 26, 2007, at 8:13 PM, Bill Northcott wrote:
As far as I can see the only one of the problems which you describe
likely to be fixed by using Xcode is linking and possibly some ABI
issues, but certainly not if you are using Fortran anywhere in the
package. Endian issues, archiving and so on seem to me to
functions of the code not the build system. These issues are nasty
but they are nothing to do with autotools.
Maybe you didn't read my original post on converting an autoconf
project to use Xcode?
One of the steps is to capture any endian, ABI, and API details
specific to a particular architecture and platform combination in the
appropriate set of header files; typically one header file named
'config.h'. Once done, the architecture specific stuff that
autotools normally takes care of is now encapsulated in the header
file(s).
This is exactly what autotools does, only it does it in a fashion
that is quite precisely incompatible with compiling for multiple
architectures in a single pass.
If you add an Xcode build to an autoconf project, you then have two
build systems to maintain instead of one. What I have done is to
use Xcode with script build steps to drive the autoconf build
system, while getting the good stuff with code indexing debugging
etc..
Not really -- do it once and adding additional source files is
generally just a matter of dropping 'em on the right group/target in
Xcode.
I'm not trying to make a mountain out of a mole hill, here. I used
to have the same attitude towards autotools -- just pass "-arch i386 -
arch m68k -arch hppa -arch sparc" and all was well. Until it wasn't
-- until my code used some new API in my supposedly correct multi-
architecture binary open source goop started breaking on 2 of the 4
architectures.
And I'm not the only one. The Python on Tiger suffers from exactly
the same problem. There are a number of the compiled modules that
suffer from endian related issues on Intel because of passing "-arch
ppc -arch i386" to a build system that derived settings from the
local build environment.
With the introduction of 64 bit Carbon and Cocoa in Leopard....
http://www.apple.com/macosx/leopard/64bit.html
.... as the number of differences between 32 bit and 64 bit ABIs is
quite significant.
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