OSDev.org

Tim here,
I am getting 50 ERRORS, all of them saying that there are undefined references. I need to ignore these errors so I can move along. I know I finished it with the best accuracy.
Any suggestions?
Tim from Russia

TimothyWilliams wrote:Any suggestions?

Yes.

Don't ignore errors. They are, as the name implies, errors.

What compiling flag in order to ignore output errors should I use?

TimothyWilliams wrote:I am getting 50 ERRORS, all of them saying that there are undefined references. I need to ignore these errors so I can move along.

You're two days late with the joke. Just move along. If you can. Those errors are probably telling you that you've got no engine, no wheels, no road...

TimothyWilliams wrote:What compiling flag in order to ignore output errors should I use?

Use the flag "--help".

Undefined reference errors can't be ignored. They mean either a) your program is trying to use functions or objects that don't exist, or b) they do exist but you're invoking the linker incorrectly so it doesn't know about them.

Pro-tip: If it is a warning, you can ignore it, BUT you should do that if and only if you know exactly what the warning refers to, why it is coming up, and why it shouldn't be a problem. Errors, on the other hand, are showstoppers - you can't ignore or disable them, they indicate a problem which is severe enough that it prevents the compiler and/or linker from creating an executable at all.

Put simply, while ignoring a warning is a mistake most of the time (we recommend turning as many on as possible, in fact - the -Wall switch is the least you should have set), an error is something the compiler can't ignore.

So, can you post a transcript of the error messages, along with your Makefile or Project file (C::B can work with make, but by default it uses its own project manager) and linker script (if any), please?

Actually, I never would go for less than "-Wall -Wextra", and I still would recommend perusing the manual to find out about the many other useful warnings not included in those two.

FWIW, this is the warning list from my current nine-to-five C++ project. Note that the otherwise useful "-Wswitch-default -Wsign-conversion -Wconversion" were intentionally disabled because I am workin g with a legacy codebase that would give thousands of warnings with those enabled. I managed to remove all the warnings for:

-Wall -Wextra -pedantic -Wmissing-include-dirs -Wfloat-equal -Wundef -Wcast-align -Wwrite-strings -Wlogical-op -Wmissing-declarations -Wredundant-decls -Wshadow -Wno-system-headers -Wno-deprecated -Woverloaded-virtual -Wunused-variable -Wunused-parameter -Wunused-function -Wunused -Wabi

I admit to not having sanity-checked these in the last two years or so, so there might be some redundancy involved.

@Solar: That's excellent advice, and useful information.

@timwilliams: something just occurred to me, and while I doubt it is relevant to this particular issue, it will certain come up soon enough: is your OS-Dev GCC installation set up as a GCC Cross-Compiler? If not, we strongly recommend that you create a separate cross-compiler (C::B should be able to set up projects to use the cross-compiler version for your OS dev work, without interfering with any 'normal' development).

I am also going to repeat the advice we've given you before: set the IDEs aside entirely for a while and use the command line, so you get a feeling for what is actually going on without the helpful-but-often-confusing IDE getting in the way. You can use a more basic programming editor for editing the code, such as Emacs, Sublime Text (which isn't free, but enough programmers swear by it that I'd be remiss if I didn't mention it), Notepad++, TextPad, SCiTE, or Light Table (which is pretty good, IMO, but as I said earlier is still very young and a little rough around the edges) - or any of the hundreds of others you can choose from. There is no rule saying that the build and project management has to be integrated into your editor. You may even decide that it is less of a hassle than the IDEs were, something that a lot of experienced programmers agree on. A good IDE is a powerful tool, but it can get in the way - especially when you are starting out and trying to understand what is going on.

For Windows, I recommend installing Cygwin, rather than using the MinGW version of GCC that is bundled with Code::Blocks, as it gives you a much more complete Unixoid environment. Note that (as is explained in the cross-compiler page) you will need to explicitly select the following packages when you run the installer: GCC, G++, Make, Flex, Bison, Diffutils, libintl-devel, libgmp-devel, libmpfr-devel, libmpc-devel, Texinfo. There are several others you might want to install as well, but those are pretty much the minimum for the job.

For the shell, you can use Powershell, but you will probably get better results if you use the version of BASH that is bundled with the Cygwin build. Once you have Cygwin install, use that to build a separate cross-compiler, making sure that the xc has a different name from the 'standard' Windows build of GCC (something like 'gcc-myos' perhaps).

Alternatively, you can set up a simple Linux installation (either dual-boot, if that is an option - it probably isn't, and would be a hassle anyway - or in a virtualizer such as VirtualBox or VMWare) and use that. While that has some distinct advantages for OS work, it means learning a new OS and using it, so that's unlikely to be the best course of action unless you want to take a few weeks or months learning Linux before proceeding. If you do that - especially if you are using a VM - you will probably want to pick a distro that is more minimalistic, such as Puppy or TinyCore, rather than a full-featured one such as Ubuntu or Fedora; Distro Watch provides a lot of information about what different distros are like, and Wicked-Pedo has a list of lightweight distributions that would fit the bill.

On second thought, that would probably be a good idea anyway - it might help you get a better understanding of what different OSes are really like. If you only know one OS - be it Windows, and specific Linux distro, or MacOS - you probably need to expand your horizons a bit to really see how approaches to OS issues can differ. Hell, it might even be a good idea to walk through the Linux From Scratch build process once you are comfortable with Linux in general, or at least read through the documentation on it - it can be a real eye-opener about what building a production-grade OS installation really means. Regardless if what you might think of Linux - plenty of people here hate it, and even those who like it often find it aggravating - you can learn a lot from it that way.

Spending some time on a Mac wouldn't be a bad idea, either. Maybe set up a few VMs for things like FreeBSD (a simple install of it should have come with Bochs, actually), Kolibri, Pintos, SkyOS, Ghost (you're in the right place for help on that!), Haiku or Syllable, while you're at it. You might even set up an emulator for one of the older systems such as Apple II or Commodore 64 and get a feel for what those were like. Getting a broader view almost always helps.

I do not have a GCC Cross-Compiler. Suggest me some flags that I can use with Code::Blocks MinGW.

There is no set of flags you can use with the stock MinGW compiler to get the full benefits of a cross compiler. You can get partway there by looking into freestanding mode (-ffreestanding, though that flag on its own is likely insufficient).

Really you should set up a cross compiler, though- it's extensively documented on the wiki and you can set it up as part of your MinGW installation.

It was all fixed without having to make a cross-compiler because it will take ages to complete it. Case closed until further notice.

TimothyWilliams wrote:It was all fixed without having to make a cross-compiler because it will take ages to complete it. Case closed until further notice.

It should only take a few minutes to build binutils and gcc on any reasonably fast and modern computer. Even if it takes an hour or two, it's still worth the time.

You should really try and get one working, continuing to use your system's compiler might lead to some really funky and hard to debug issues that nobody will want to help you fix.

TimothyWilliams wrote:It was all fixed without having to make a cross-compiler because it will take ages to complete it. Case closed until further notice.

The thing is, writing an operating system is much, much more difficult than following straightforward instructions to produce a cross-compiler, so why make life more difficult for yourself.

If you are unable to complete the latter task then the former is most certainly beyond your capabilities.