iOS cross compiling support

James Gregurich bayoubengal at
Fri Jan 28 16:52:10 PST 2011

On Jan 28, 2011, at 4:38 PM, Joshua Root wrote:

> On 2011-1-29 10:49 , James Gregurich wrote:
>>>> for the record, the precise definition of my terms are....
>>>> host = system with dev tools that builds the product
>>>> target = system upon which the product executes.
> In the autotools world these are the --build and --host options
> respectively. There's also --target which is used when you're building a
> compiler.

yes. I'm aware that these terms are used in their own way in the autoconf world. That's why I defined my terms.

> Looking back through the thread, I don't see an explanation of why you
> need to figure out the build system's triplet yourself. Configure
> scripts will typically come with a copy of config.guess and figure it
> out on their own.

How would config.guess know what the target hardware/os is for an iOS device given it doesn't run on the iOS device? building icu for iOS requires that you pass --host=arm-apple-darwin to the configure script.

> It should also be noted that build systems that handle cross compiling
> correctly are actually not too common (even among the ones that use
> autotools).
> - Josh

well, I see no reason why macports couldn't be used for cross compiling in general. However,  each port will have to customized to handle cross compiling. I had to add custom steps to the icu portfile. For ports that I need for my work, I can certainly supply the needed portfile changes.

It may be possible for someone who knows more about the internals of macports than I do to actually rework the mechanism so that changes to portfiles will be minimal, but my goal was just to get something working. I had a large enough learning curve without trying to get too fancy. However, the approach I took should not break existing ports....they simply won't build for iOS because they will be depending on variables that are configured for the host.

More information about the macports-dev mailing list