Cross Compiler

[frank]

@OP
One time I had a really hard time building a cross compiler in Cygwin. I did everything exactly right and it would just fail with some obscure error message.

When you run the setup program for Cygwin you must pick binary as the file access type. You can rerun the setup and just change the option, it didn't take a complete reinstall for me.

[skyking]

First of all what kind of cross compiler are you needing? To me it seems that there is not much of a cross compiler since cygwin almost implies you're using a pc and your target seem to be i586(=pc), so all the fuzz is about emitting elf instead of PE? To me that's not much of a cross compiler.

I think that for OS-deving you should know your toolchain and I don't think that a cross compiler is actually needed in this case. In cases where cross compiler is really needed it's a whole different story and the task may no longer be that trivial as following a simple tutorial (since you can easily run into unsupported configurations, and the build process is quite long).

[Solar]

Why an OS developer should build a cross-compiler

Creating a dedicated (cross-) compiler for your OS development work can save you many headaches. If...

* ...your system compiler drags in references to alloca() or other OS-dependent things,
* ...Cygwin complains about "PE operation on non-PE file",
* ...your compiler and your assembler can't agree on binary formats ("unresolved reference to _kmain()"), or
* ...your bootloader stubbornly insists that it cannot read your kernel binary,
* ...you are using Mac OS

the most effective solution is setting up a dedicated cross-compiler. If anything, it places you on the same playground as other users: You can rest assured that any problems you might yet encounter are not specific to your compiler setup.

Don't fear, it's easier than you might think.

[Love4Boobies]

Well yeah, but since this is OSDev.org I'm assuming that we should only cover what an OSDev'er is supposed to know. If there's anything else one can take advantage of that's great but that doesn't mean we should start writing tutorials for things that an OSDev'er would be able to do himself easily. Anyway, that's just me; I won't delete any information about this on the wiki if you have the time to add it

Just a quick note: MSYS, which just like Cygwin is a POSIX-like environment under Windows (and can be downloaded from MinGW's SourceForge page) works pretty much the same way as Cygwin. In the end it's the GNU build system we're after (and probably a few other tools like sed that are used for make install or for generating dependencies) and it works the same way whether compiled natively (i.e., what you get in MSYS) or under Cygwin. I did however notice a few bugs (race conditions?) with it.

One of the reasons I prefer to use a natively built toolchain is that I'm more familiar with the Windows environment so I can't see why I'd build a slower toolchain (noticeable or not for my still-small project) just to work in an envrionment I'm not used to. I'm not imposing anything on anyone.

[Combuster]

From what the MSys homepage is telling me, MSys is just a bunch of windows ports of way-too-often-used linux tools and nothing more. In contrast to cygwin and what you just told us, msys does not emulate a unix host - it emulates unix commands.

The net result is obviously good enough to get gcc (which in itself is not unix-specific, just uses *nix commands) and whatnot to compile. Depending on what you want, msys might be the good choice, or it might not. In my case, msys is not enough since it doesn't grant me access to things like /dev/fd0, which I regularly need to write out floppy images.