Talk:Cross compiler

Source-to-source translator
I am removing the "Source to source translator" from the Uses of cross compilers section for these reason: --205.143.141.24 (talk) 00:25, 13 April 2010 (UTC).
 * It is inconsistent; It does not represent a use of a cross-compiler but a different definition of it that is unrelated to the article as a whole.
 * It introduces ambiguities: it conflates different concepts into the term compiler.
 * Source-to-Source translation was already addressed (with a redirection to an appropriate page) in the introduction.

I did a few Google checks, and it looks like the hypen dies. That is "cross compiler" wins over "cross-compiler". English, she is a difficult language.

Also, this is closer to a three way merge. There is a good write up on cross compilers in the compiler article.

I disagree. The cross compiler portion of that article links to here and so it should stay. There are only a couple of sentences in that one and it reads more like a dictionary definition than anything encyclopedic. I went away as dumb as I was when I first read the "good write-up". I guess I am just a grumpy old man:) so I'll try to be a little more positive. It's OK but should still link to here, and it does. It's not broken.

--Bill Buckels (talk) 23:07, 9 March 2008 (UTC)

Canadian Cross
The section on the Canadian Cross lack context and an explanation of why it is done this way.

Jorge Peixoto 15:45, 9 February 2007 (UTC)

Some knowledge of how Canadian Parliament worked at the time including who the Liberals, Conservatives, and NDP Parties are would probably help you in your understanding. It would probably be clearer if a Donkey and an Elephant had been used, but nothing analoguous to a working-man's party really exists on a national scale directly South of The True North Strong and Free and cultural awareness has not traditionally been bi-directional, but to this Canadian Software Developer the "punnery" of it all makes perfect sense. In this context GNU must be the Bloc Quebecois which also makes me chuckle a little.

--Bill Buckels (talk) 23:51, 8 March 2008 (UTC)

I am Canadian and I still didn't understand why the compiling is done that way. A further explaination (using no or clearer metaphors) would be greatly appreciated. Grant E 67.43.138.51 (talk) 21:19, 17 April 2008 (UTC)

Aztec C
Aztec C and cross compilers were not necessarily common to some in the world of professional micro computer development back in the 1980's when I was cutting my first C code. Aztec C certainly was. Other developers like John Bridges who wrote PCPaint, the first Paintbrush Program on the IBM PC, used Aztec C for his first versions.

To me it never made sense to sit and develop programs on an slow old Apple II or Commodore 64 even if they were still in use by School and Home Markets. Like most developers, I didn't have much time to waste and using my IBM PC to write the programs in a cross compiler was by far the most productive use of my time, not to mention the most comfortable, since I always felt cramped on those "little boxes".

The GNU stuff came later and so did developing for the ARM processor which by the way Microsoft also offer a cross development environment for amongst others, so I put the Aztec C section at the top. I was however somewhat sensitive to the reasons for cross compilation and stuck my bit about emulators and enthusiasts at the bottom of the list. It is still notable though and deserving of its own unique purpose.

As far as the hyphen winning... it's optional. I didn't use it for this article but have used it professionally on and off in my own stuff for a lot longer than I would care to admit. As far as merging goes, I am against it with the rationale that cross compilers are special cases and do not deserve to be subclassed to some kind of a forced inheritance. It's analoguous to having two kingdoms in the world of compilers. 'Nuff Said.

--Bill Buckels (talk) 23:51, 8 March 2008 (UTC)

Microsoft C
After adding the section about Aztec C I thought about-it for a bit and then decided I'd best tell the rest of the story. The GNU-ish stuff seemed a little too parochial for my liking, lacking of the substance that led us here, but I didn't necessarily want to promote M$oft despite the fact that I have used their C compilers for almost 25 years. I have developed extensively in Unix and not just Linux over that time as well. I have done HPUX, Solaris, Sun and have had my share of AIX (and Panes too) since coming off the mini's back in the mid-80's and focusing on micros. I wrote what I wrote from memory so at least I haven't lost my mind completely throughout.

Now what I really want to leave you with is a "higher bar" for the rest of this article. There is lots more to tell and this isn't a dictionary... it's an encyclopedia. Some of the articles on WikiPedia are pretty constrained, and much is missing that is relevant, so when I do one I consider it a privilege to provide as much content as possible. This one is still no different and needs work, but two major wacks have been added, and in my opinion the two most significant.

After I wrote the section about the "Little Engine That Could but later ran off the rails", I slept on it, then I picked on the "Cash Cow that sat on the track and derailed them". Hope you enjoyed it.

--Bill Buckels (talk) 22:56, 9 March 2008 (UTC)

Separate article
The "Microsoft C cross compilers"-section should be used to create the Microsoft C/C++-page (linked from Visual C++). Calling MSC a cross compilers dilutes the terminology.

--Bjornen 11:44, 12 September 2008 (UTC)


 * I thought the same thing. There is a lot of valuable information there; more than what is at Visual C++, which is where I just redirected Microsoft C to. Most of the early history information is not directly relevant to the topic of cross platform or cross architecture compilers though, except perhaps the parts on the barcode reader, the 16 vs 32 bit code generation, and the “Late 1990s” section. It does mention “cross language development” a lot, but that is different. So I am thinking the information could be split off to a Microsoft C, or even a more general Microsoft development tools (see the category) type article. Vadmium (talk) 06:47, 6 August 2011 (UTC).

MSC 8.00c
The 1990's section mentions that 16 bit was supported until MSC 8.00c. MSC 8.00c still had 16 bit support, so perhaps this should read 16 bit was supported through (as opposed to until) MSC 8.00c.

Jeffareid (talk) 11:05, 3 January 2010 (UTC)

Plan 9 C compilers
I believe some mention should be made of how Plan 9 handles cross-architecture compiling. In short, there's a separate compiler targetting each architecture, which outputs object files named according to the target architecture. This makes cross compiling completely painless. The reference is http://plan9.bell-labs.com/sys/doc/comp.html. 78.52.197.102 (talk) 09:38, 26 March 2008 (UTC)

Flaming Thunder

 * Moved from the article. There are no reliable third party sources establishing the notability of this cross compiler.  silly rabbit  (  talk  ) 01:09, 4 May 2008 (UTC)

Flaming Thunder is a single-asset 8-by-8 shotgun cross compiler.

Cross compilers have inherent O(mnp) weakest-link and version-coherence ("DLL hell") problems, where m is the number of assets (files) in the tool chain (executables, libraries, etc), n is the number of hosts and p is the number of targets. For many cross compilers m, n and p are roughly comparable, so that the maintenance and debugging problems are roughly O(n3). A single-asset n-by-p shotgun cross compiler, such as Flaming Thunder, reduces those problems to O(n), the theoretical minimum.

Flaming Thunder supports 8 major architectures: FreeBSD 32, FreeBSD 64, Linux 32, Linux 64, Mac OS X Intel 32, Mac OS X Intel 64, Windows 32 and Windows 64. There are a plethora of minor versions within those major architectures (for example, Windows 64 includes both Windows Vista Ultimate 64 and Windows XP Professional x64, among others), but they are not counted as separate targets because the executables generated by Flaming Thunder auto-detect minor differences. Flaming Thunder, running on any of those 8 architectures, can produce executables for any of those 8 architectures, so Flaming Thunder is an 8-by-8 cross compiler.

Flaming Thunder is a single-asset cross compiler because all of the tools and libraries that Flaming Thunder needs are internal to the executable file for the Flaming Thunder compiler. Flaming Thunder compiles directly from source code to stand-alone statically-linked executables without using any external tools or libraries.

When running on a particular host, many cross compilers not only require external tools or libraries, but they require different versions of those tools or libraries for each target. Flaming Thunder, however, is a shotgun cross compiler: it can hit all of its targets using only the single executable file for the Flaming Thunder compiler. For example, the following command line (ft is the name of the compiler):

ft file myprogram.ft target all

will produce 8 target executable files: myprogram-f32, myprogram-f64, myprogram-l32, myprogram-l64, myprogram-m32, myprogram-m64, myprogram-w32.exe and myprogram-w64.exe.

Dot net??
Is it just me or does the .NET section make no sense. It just blabs on about how .net isn't a cross compiler in the true sense -- to use hyperbole, my refrigerator is not a cross compiler in the true sense, I wouldn't put things that are *not* cross compilers in the article. That section seems to detract from the article, in a sort of incoherent rambling manner... 121.44.93.244 (talk) 05:26, 23 August 2008 (UTC)

Dot You??
It is just you.

The .NET section makes perfect sense.

It needs improving but belongs here. It is included for continuity (I wrote it as part of my Microsoft Timeline) and perhaps in a separate part of this article Java and Ruby should be mentioned too and the Model View Controller, but this is a community article and you could as easily add these as I.

As far as "blabbing on", your unsigned hit-and-run comments are why Wikipedia should require a valid login. We don't know who you are so how do we know if we should take you seriously. When you say what you would or wouldn't do it means nothing.

You do in spite of your insect-like rant make one good point but your lack of respect combined with the fact that you do not sign your comments is less than inspiring so I am just not going to tell you what that point is. You will need to read the article again to figure that out:)

--Bill Buckels (talk) 13:20, 20 December 2008 (UTC)


 * Bill, this article is about compilers that execute on one platform while generating an executable for another platform. Your whole section about Microsoft is very informative and well made, but it belongs in an article about Microsoft compilers (say Microsoft C as suggested by another contributor somewhere on this talk page). As far as I can tell, the sections you added talk about 'multiple-languages-at-once compilers', not 'cross-compilers'. Olivier Diotte (talk) 00:48, 24 April 2015 (UTC)

build/host/target triplet definition
I edited the build/host/target triplet definition of the "GCC and cross compilation" section. According to the 2 references I linked, the previous definitions were wrong (and there was no reference, so I assume the information I found is right). Olivier Diotte (talk) 22:56, 24 July 2011 (UTC)

The build/host/target example is confusing and seems to contradict the definitions before it. Which is right?

more semantics could be added - to the enumeration
we need more than a enumeration of compiler translating from one pl to another or even maschine code.

when you got the grammar (ex. ebnf) of a pl the structure can sometimes be transformed in the grammar of another pl. then it's neccessary to transport the semantics (ex. statements statement sequences expressens...). maybe multiple passes are needed on the code of the program after parsing the source code.

79.234.208.36 (talk) 18:10, 24 October 2013 (UTC)

Microsoft C section out of place
Fortunately the material on canadian cross compilation is informative. Unfortunately, the Microsoft C section is grossly misplaced. The Microsoft C compilers are native compilers. I'm not signing this only because this should be obvious. 70.181.197.149 (talk) 04:38, 14 September 2015 (UTC)

I second this and ADD a section on crossing that is super important in consideration. Android SDK compilers for "target android". (while that sounds cool, Java did this 3 decades ago ?!) ORACLE JAVA IS A CROSS TOOL IN IT'S OWN WAYS.

It's important if the Compiler can build itself as a target, build libc as a target successfully too (excuse me w/o weeks or years of build fails ulibc?) (glibc is known to not be easy) and a few tools, and if a Kernel is willing to be built as a target (running on build processor) (the kernel will not necessarily like it, i believe Linux cannot do it).

A "real cross compiler" referred to by Kegel is "really able to cross the Great barriers" whereas simpling having GCC running in 64 kernel target 32bit simple app is actuall NOT a cross compiling. Its running on 32bit and creating 64bit that IS crossing. But IT IS IMPORTANT if the compiler can target itself, it's tool chain, and get on the targe system with the apps (a large and greatly macro-ized hacked libc and gcc would find doing this like going through the eye of a needle, unfortunately).

What the article doesn't omit is the idea who makes chips (say, nxp) and if the compiler knows these utiltiy chips language is part of what cross targeting is about. Some small china multi-function chips come with Win10-only programming tool and docs (small chips, cheap, many things timers and io). For many small chips there is no cross tool you must use the vendor's provided flash-upload sdk for the chip.

But make no mistake - gnu linux cannot easily cross itself and crosses will be seen again in future. It's a wonder if everyone will or won't be using java or intel compilers by then due to ... the awsome breadth of coverage today's cross compilers need to really hop platforms (with any meaningful software intact). — Preceding unsigned comment added by 2601:143:480:A4C0:513:C451:61AC:ED2A (talk) 09:46, 30 April 2021 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 1 one external link on Cross compiler. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Corrected formatting/usage for http://www.objsw.com/CrossGCC/FAQ-4.html#sec:CanadianCross

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.—cyberbot II  Talk to my owner :Online 08:40, 1 April 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 1 one external link on Cross compiler. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive http://web.archive.org/web/20071215083657/http://www.itee.uq.edu.au:80/~csmweb/decompilation/hist-c-pc.html to http://www.itee.uq.edu.au/~csmweb/decompilation/hist-c-pc.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.— InternetArchiveBot  (Report bug) 17:29, 21 July 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Cross compiler. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20080501141058/http://members.fortunecity.com/pcmuseum/dos.htm to http://members.fortunecity.com/pcmuseum/dos.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 21:14, 14 August 2017 (UTC)

Cross compile terminology
I've seen it alluded to but is it the case that if the host platform can somehow run the target platform's binaries without the aid of an emulator then it's not a "true blue" cross compile? For example:
 * 1) If I am on a 64 bit Intel platform and a compile a binary for 32 bit Intel target using -m32 this is not a "true blue" cross compile because I can run the resulting binary if I have the right libraries installed and I don't need an emulator.
 * 2) If I am on a 32 bit Intel platform and I have a means of compiling a binary for 64 bit Intel target this is a "true" cross compile because without an emulator I can't run the resulting binaries on the host.

Is this a real thing or is it just a minor debate point? For arguments sake let's cover a) the case where the compiler is the same binary as one targeting the host platform and just a flag (such as -m32) is used and b) the case where the compiler is actually an entirely separate binary from one that would target the host platform (e.g. i686-w64-mingw32-gcc vs x86_64-w64-mingw32-gcc).

37.152.218.185 (talk) 08:44, 24 September 2017 (UTC)


 * According to https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html if the build and the host machine are not the same then it's a cross compile. Perhaps host-x-host ?


 * 51.9.218.247 (talk) 16:16, 4 November 2017 (UTC)