RE: More about cross compiling
RE: More about cross compiling
- Subject: RE: More about cross compiling
- From: Jeff Laing <email@hidden>
- Date: Fri, 29 Oct 2004 08:45:17 +1000
> > To "compile gcc as a cross compiler" would mean, for example, that
> > Apple would have a gcc that runs on a PPC cpu, but generates output
> > for an INTEL cpu.
>
> Not necessarily. Depends on where you draw the line between "native"
> and "cross". If you want an environment for generating Linux-PPC
> binaries on OS X, the processor and maybe even the hardware is the
> same, still most people will consider it as an cross compiler.
Agreed.
> > I can't think of a good reason why Apple would do this as their
> > standard product.
>
> If you draw the line between major Mac OS X releases? Consider OS X
You take my original comment out of context. What I said was...
> > To "compile gcc as a cross compiler" would mean, for example, that
> > Apple would have a gcc that runs on a PPC cpu, but generates output
> > for an INTEL cpu.
> > I can't think of a good reason why Apple would do this as their
> > standard product.
... which I don't think has anything to do with Apples rather oddball notion
that compiling for 10.2 on a 10.3 box is "cross-compiling".
> 10.2 as a different platform than OS X 10.3? You need a different set
> of headers and libraries to get the right output. This ist what Apple
> did and why they call it cross compilation.
I'm a firm believer in "if the cpu/executable format is different, its
cross-compiling". Others are entitled to their own opinion. However,
calling what XCODE does cross-compiling has clearly confused some of their
user-base who expected that a "cross-compiling xcode" would be able to do
Linux or x86, etc...
> While in theory, you could serve all three OS X (10.1, 10.2, 10.3)
> environments with a single compiler, Apple has choosen to use the
> compiler recommended for each release just before the next release came
> out. This is gcc-2.95.2 for OS X 10.1, gcc-3.1 for OS X 10.2 and the
> current gcc for the current OS X.
As far as I'm aware, this is because at each release they've changed header
files to exploit new features, or to avoid bugs in specific gcc releases,
and perhaps for added altivec support.
I find the phrase "Apple has chosen to use the compiler recommended..." a
rather strange one. Who exactly does the recommending if it isn't Apple?
> > As far as I know, this is no magic command-line switch that can be
> > passed to gcc to have it generate code targetting a different CPU.
>
> -mcpu=750, for example. This switches between different PPC versions.
>
> For a completely different CPU like MIPS, Sparc, x86, etc., you have to
> switch at gcc compile time.
Which is what I said initially.
> I'd always recommend the sources you would use in the native enironment
> of your target. This is FSF gcc for (almost) any target other than
> Darwin/OS X.
My understanding was that the FSF sources tended to lag slightly behind the
ones that Apple uses to build its toolchain, because the Apple guys are
"just another contributing developer", from FSFs perspective, and presumably
they (FSF) code-review whats submitted before accepting it into their main
releases.
Thus, downloading directly from the FSF might not get you the same thing as
downloading from opensource.apple.com, or whatever the site is that Apple
makes Darwin available on. And I know that the one time I tried building
the stuff from there, I got so many problems I wrote it off as a worthless
exercise (it needed way too much undocumented stuff set up)
_______________________________________________
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