OSDev.org

Correct me if i am wrong:
It is actually cross compiler/linker. And is simply a compiler and linker chain which has the flexibility to accept what ever input we give and will not implicitly use some platform dependent libs or formatting.

So the reason for example that we cannot use MS Compiler is because it has predefined formats, libs, code generation and linking settings. And as soon as a build chain has enough flexibility, we can use it as a cross-compiler. An i right?


First I should note that I searched about this in the forum. But it was inefficient. Because with a lose search terms it brings too many results and when I tighten the terms there is no result.

The definition of a cross-compiler (or cross-toolchain for the whole package) is a toolchain that by default does not generate binaries for the system it runs on.

That doesn't mean the tools you might have can't be beaten into submission to behave pretty much the same, but such slavery typically ends up in revolts. Which is why you must use a crosscompiler for GCC. Using the VS compiler is not often done because the only option there actually means beating it into submission - with all problems thereof.

The issue of cross-compilers is actually a corollary of a much more basic theorem of compilers:

Sortie randomly inventing compiler theorems wrote: (1) A compiler must be correct.

From this it follows:

Sortie randomly inventing compiler theorems wrote: (2) A compiler must target the intended target,
(3) Otherwise, a compiler cannot reliably compile and is not correct for that purpose.

Informally:

Sortie randomly inventing informal compiler theorems wrote: A compiler must know what is going on otherwise you cannot expect the compiler to be correct.

When you develop a new operating system without using a cross-compiler, you are violating (2) (and thus (1)) because you lying to the compiler (it still thinks it is targeting Linux or whatever your build system is) rather than the fact that you are targeting a new operating system (your own). That's why when you #include headers it gets them from /usr/include; that's why when you link against libraries it gets them from /usr/lib; that's why it declares the preprocessor symbol __linux__; and so on. The compiler is correct from its point of view, it doesn't know you are violating (2). In other words:

Sortie randomly inventing other words wrote: The compiler that came with your distribution that targets your distribution is not a compiler for your OS because your OS is not the local system you are using, thus you cannot use it for osdev.

You can, however, use a gcc cross-compiler in accordance with the above theorems because you don't violate (2) by letting the compiler know it is not targeting the local system, but rather that it is a cross-compiler for a bare system. This is good enough, though you'll want to teach the compiler later on what your operating system is.

As for Visual Studio?

Sortie inventing corollaries about Visual Studio wrote: Visual Studio targets Windows and your operating system is not Windows, therefore Visual Studio doesn't target your OS and is not correct for the purpose of compiling your OS. Additionally, you cannot port it or teach it what your operating system is due to its proprietary nature.

You should understand that it is absolutely irrelevant whether your compiler is a cross-compiler, but that the important part is that the compiler targets the correct target. For example, it is still wrong if you use a cross-compiler running on your i386-linux-gnu system that targets powerpc-elf to build your x86_64 ELF kernel, even though it is a cross-compiler it is the wrong one. For example, if you port gcc to your x86_64-myos system and it targets x86_64-myos then you can use it to build your operating system, even though it is not a cross-compiler.

Thus, don't tell people as such to unconditionally use a cross-compiler, but to use a compiler that targets the intended system and that the compiler that came with their distribution doesn't target their intended target, thus they need a cross-compiler in their particular case (until they go self-hosting).

Note that Visual Studio typically refers to the entire toolkit of IDE, compiler, and linker. It is possible to use the IDE functionality of Visual Studio and configure it to use a different compiler/linker (one that is a cross compiler). That is much different than bastardizing the visual studio compiler to try and pretend it is a cross compiler.

@sortie It's already pointed out but I think you're referring to CL.EXE which is the Microsoft's Compiler VS(C) just uses that Compiler by default.
I think one can change the compiler the compiler(M$'s one), without any Windows Bloat, which can yield a stand alone PE file.
BTW VS includes a lot of bloat , even VC#, Visual Web Developer etc. are the part of Visual Studio.

Bender wrote:@sortie It's already pointed out but I think you're referring to CL.EXE which is the Microsoft's Compiler VS(C) just uses that Compiler by default.

Of course, my remark about Visual Studio was just a side remark and I wasn't precise, but yes, of course I meant the C compiler itself rather than the IDE. It doesn't really matter.

Rew wrote:Note that Visual Studio typically refers to the entire toolkit of IDE, compiler, and linker. It is possible to use the IDE functionality of Visual Studio and configure it to use a different compiler/linker (one that is a cross compiler). That is much different than bastardizing the visual studio compiler to try and pretend it is a cross compiler.

That's what I am doing actually. I use custom build tool to tell IDE how to compile files. But I think I will use another IDE soon, once I master make.