Actually, the first one, the conflict on the function name
memset(), is one which is pretty uncommon outside of OS-dev. The others, however, you are correct about.
That specific problem relates to the use of a stock, host-targeted compiler configuration without the
--fnobuiltins option (or
--ffreestanding, which includes the no-builtins effect and is the recommended usage), rather than a cross-compiler and a
Makefile with the appropriate settings baked in.
The crux of the matter is that GCC will automagically inline certain standard functions, including
memset(), unless told otherwise. The code it generates for them isn't from a library, but built into GCC's code generators themselves. Now, not all GCC backends have the same built-ins, but most will include a suite of 'functions' that aren't actually implemented as functions.
The problem arises from the fact that the backend implementations have to be aware of the target environment to some degree (in order to know which type of
Object Files to generate and so forth. While most GCC installations include several different backends to facilitate cross-development, using them with an out-of-the-box configuration for your host platform means applying options, having different linker output, and more; for OS development, this quickly becomes impractical. This is why we alway recommend configuring a
GCC Cross Compiler and a
OS Specific Toolchain which avoids both ambiguity and repetition.
I recommend that you reference the
GCC documentation for the version you are using (the current version is 7.3.0, but there is a high likelihood that you are using an older version, so make sure you read the correct one). This
Guide to Bare Metal Programming with GCC would be useful to review as well, though you will want to keep in mind that it is mainly aimed at writing standalone programs on the Raspberry Pi rather than on PC operating system development.
Now, normally I would say that it would help us if you could post more details about your development environment, things like what kind of host system (hardware and OS) you are using, what emulator or virtualizer you mean to run the test OS in, what versions of GCC and binutils you are working with, and so forth, but this may be premature.
Hexcoder's basic point is correct: most of those errors are ones which can come up in any C programming project, and the fact that you don't know how to address them indicates that you don't have enough general programming experience to tackle OS dev. I strongly recommend shelving this project for a few months, or better still a few years, while you build your general programming skills up.
I will add one more piece of advice which too many others have ignored: if you haven't set up version control (such as
Subversion,
Git, or
Mercurial) for your software projects, with an offsite repository (on a free host such as
Github or
CloudForge), drop everything and do that now for
every project you intend to work on. We cannot stress the importance of this enough. Sooner or later, you
will make a terrible mistake that wrecks the code you are working on; sooner or later, you will have a hardware failure that has the same result. This happens to every programmer, without exceptions, and the best protection you have for that is offsite version control. It is more than just a backup system, however; it gives you a record of your work, and makes it easy to collaborate with others on a project. You owe it to yourself to do this, even on 'little projects' that you don't expect to be important - little projects have a way of becoming big ones, of which two prime examples are the Linux OS and the Perl programming language.
Unfortunately for you it doesn't work that way. You need to learn and understand how interrupt handling works and fits into the picture. Chances of copied low-level system code working as-is are close to zero.
: