OSDev.org

Combuster wrote:Nor are you using the GCC Cross-Compiler

I dislike people harping on about this. On most linux systems you *do not need to build an explicit cross compiler*. The packaged one works fine out of the box.

[Edit by AJ - topic split from http://forum.osdev.org/viewtopic.php?f= ... 05#p205995]

*Sigh*

It's been discussed to death. Can we please bury the subject, or at least discussing it on the appropriate Wiki discussion page instead of every other thread where this recommendation is mentioned, over and over again?

Solar wrote:*Sigh*

It's been discussed to death. Can we please bury the subject, or at least discussing it on the appropriate Wiki discussion page instead of every other thread where this recommendation is mentioned, over and over again?

I've made a comment in the discussion page saying I completely disagree with all of you except Love4Boobies.

Provided what the OP posted, his setup only works properly if he's specifically using 32-bit linux, and specifically not 64-bit ones. I give him 90% chance of failing later without either using the recommended toolchain or adding toolchain-specific compiler options to whatever he's using now.

Therefore the suggestion is legit and I consider your response slightly overreacted.

Heck, I just noticed he's sufficiently ignoring your tutorial to have introduced the typical strings-do-not-work bug. XenOS' suggestion might provide a free fix for that, but who knows.

if he's specifically using 32-bit linux, and specifically not 64-bit ones.

-m32. Well that was hard...

Quiz question for the OP: what does -m32 do?

berkus wrote:I believe building one's own cross-compiler is a sufficient toolchain handling test for any OSdev wannabe. If one can do it - well, he's got himself a cross-compiler. If one can't - time to write some userspace code first.

... and yet, utterly pointless.

berkus wrote:I believe building one's own cross-compiler is a sufficient toolchain handling test for any OSdev wannabe. If one can do it - well, he's got himself a cross-compiler. If one can't - time to write some userspace code first.

While I agree that having a cross compiler has definite proven uses in osdev, I don't see how it proves any level of experience in coding userland apps. gcc has a god-awful configure/build process that imho is fragile and prone to random failure. I have written some pretty large and complex userland apps and none have been so awful to build in a custom setup as gcc is. at best, building a gcc cross compiler is an exercise in patience at the crappiness of automake and the gnu toolchain friends, plus its only relevant if you're using gcc. I am but many others are not.

Personally I managed to get a very reasonable os up and running before needing a cross compiler at all, and then only to play with 64 bit kernels under qemu on a 32 bit system. so there's my 0.02p worth.

berkus wrote:

JamesM wrote:

berkus wrote:I believe building one's own cross-compiler is a sufficient toolchain handling test for any OSdev wannabe. If one can do it - well, he's got himself a cross-compiler. If one can't - time to write some userspace code first.

... and yet, utterly pointless.

Not at all. Some host system stuff could be nasty if pulled into kernel code by accident. xcc prevents this by not having any host stuff.

so does -nostdlibinc -nostdlib. Not to mention -sysroot.

JamesM wrote:so does -nostdlibinc -nostdlib.

Actually, my host gcc says no. It happily includes stdio.h but only complains about missing _start meaning you only fixed half the problem.

I realize it can have it's advantages, but I also realize that some people will be just as happy learning a few command line switches - so why force something down their throats?

What I would like to remind you of, is that building a cross-compiler has always been a recommendation. But nowadays it seems more and more like a obligation to even get a response on this forum other than "get a cross-compiler".

JamesM wrote:

Combuster wrote:Nor are you using the GCC Cross-Compiler

I dislike people harping on about this. On most linux systems you *do not need to build an explicit cross compiler*. The packaged one works fine out of the box.

Great, now you're relying on a vendor-supplied build.. it could contain special patches not contained in the vanilla sources, it may also be upgraded to a newer release.

I don't understand why people keep trying to avoid building a cross-compiler, you set the version that you've tested to work with your kernel.. and others can replicate your setup using a different Linux distribution or OS entirely.

It's about creating a reproducible known working environment, and not having to deal with compiler bugs across umpteen different versions that other users may be using.

I have heard of the "reproducible environment" argument before and don't see the value in it. Software with a good build environment will be able to adopt to new toolchains with ease; maintaining compatibility and creating a standard build system. If that argument is targeted toward newcomers, I still don't see it: I never seen it used on this forum for the purpose of aid.

I don't use the cross compiler because its gcc specific. Tying the software to a specific toolchain because of the build environment is not necessary.

Software with a good build environment will be able to adopt to new toolchains with ease

Exactly my argument. Fixing to one known version of a compiler guarantees that your code won't be portable.

EDIT: And I'm really not keen on the idea of a "test for OSDev entry" - it's a ridiculous idea on so many levels.

JamesM wrote:

Software with a good build environment will be able to adopt to new toolchains with ease

Exactly my argument. Fixing to one known version of a compiler guarantees that your code won't be portable.

The idea is not fixing yourself to one known version of a compiler, but to enable others to use the same version of the compiler, to rule out differences in compiler configuration as a source for dodgy problems. Or, to be able to fall back to a known version of the compiler if your package manager updated to (hypothetical) GCC 6.2 and your build doesn't work anymore. Not because you want to stay with the 5.x version, but to get the build working again, and then working towards 6.2 compatibility.

(Try installing yesterday's version of your system compiler through apt-get. Good luck.)