Page 4 of 4

Re: Why is ld complaining?

Posted: Sun Nov 20, 2016 2:00 pm
by Octocontrabass
Schol-R-LEA wrote:Second, since the stdbool.h, stddef.h, and stdint.h files are meant to wrap the system-specific types and definitions in a portable wrapper, you would need your own versions of each of those, AFAIK.
Freestanding headers like those are provided by GCC, and you shouldn't modify them or try to reimplement them unless you're porting GCC.

Re: Why is ld complaining?

Posted: Sun Nov 20, 2016 6:26 pm
by Schol-R-LEA
Octocontrabass wrote:
Schol-R-LEA wrote:Second, since the stdbool.h, stddef.h, and stdint.h files are meant to wrap the system-specific types and definitions in a portable wrapper, you would need your own versions of each of those, AFAIK.
Freestanding headers like those are provided by GCC, and you shouldn't modify them or try to reimplement them unless you're porting GCC.
OK, fair enough.

Re: Why is ld complaining?

Posted: Mon Nov 21, 2016 8:39 am
by NunoLava1998
Schol-R-LEA wrote:
Octocontrabass wrote:
Schol-R-LEA wrote:Second, since the stdbool.h, stddef.h, and stdint.h files are meant to wrap the system-specific types and definitions in a portable wrapper, you would need your own versions of each of those, AFAIK.
Freestanding headers like those are provided by GCC, and you shouldn't modify them or try to reimplement them unless you're porting GCC.
OK, fair enough.
I sometimes provide my own beacuse GCC on a 64GB SD Card (absolutely doesn't) work well and
"stdio.h not found" even though it's in literally included in the include folder.

Re: Why is ld complaining?

Posted: Mon Nov 21, 2016 8:41 am
by NunoLava1998
Schol-R-LEA wrote:OK, I see you deleted the object files, that's not bad. I would recommend (if you haven't do so already) putting a .gitignore file in your working (local) directory with the following masks, along with any others that you think you might need, which will prevent files matching those patterns from being checked in by git:

Code: Select all

*.o
*.O
*.obj
.sh
*.bak
*.*~
(The last two are masks for extensions used by some editors for backups and temporary files; e.g., if you edit kernel.c, when you save the changes the editor would rename the existing file as either kernel.bak or kernel.c~, and save the changed version as a new file.)

I also see you haven't checked in a Makefile, so I am wondering if you are using one; from what you said earlier, I assume you are using the file make.bat instead. In any case, I know several editors and IDEs have their own project file formats, so you might not find one useful, but if you need one, you can start with the one below. I had to make some guesses of the paths for your OS Specific Toolchain based on the error messages mentioned, so you will need to modify this somewhat, if not now hhen when as you add new files to the project (and/or fix the problems with the current layout). You should read the article on Makefiles in order to understand this before you use it, as I have no way of knowing of this will work on your system as-is. Hopefully, I haven't made too many horrible errors, though if some like Solar or Brendan can review it, I would be grateful.

Code: Select all

#first, set the paths where the files are to be found
# binary toolchain
BIN := I:/ghost-i686-elf-tools/bin
#
# Dixium source code path - set it to the current directory the Makefile is in
SRCPATH := . 
# system include headers
INCPATH := $(SRCPATH)/include:$(SRCPATH)/include/tty:$(SRCPATH)/include/kbd

# source code files required by the build
SRCFILES := $(SRCPATH)/kernel.c $(SRCPATH)/boot.asm $(INCPATH)/kbd/kbd.c $(INCPATH)/tty/tty.c

# header files required for the build
INCFILES := stdio.h stdlib.h include/tty/strings.h include/tty/vga.h include/kbd/stdio.h

# non-code files which should always be included with the code files
AUXFILES := Makefile README.md LICENSES

# list all the files that need to be distributed for the build, not
#including temporary files such as object or dependency files
DISTFILES := $(SRCFILES) $(INCFILES) $(AUXFILES)

# define the toolchain tools to be used and their settings
CC := $(BIN)/gcc
WARNINGS := -Wall -Wextra -pedantic -Wshadow -Wpointer-arith -Wcast-align \
            -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations \
            -Wredundant-decls -Wnested-externs -Winline -Wno-long-long \
            -Wuninitialized -Wconversion -Wstrict-prototypes
# set the compile options used by all builds
CFLAGS := -g -O2 -std=c99 $(WARNINGS) -ffreestanding -I$(INCPATH)

# compile and/or link the sources into the files given by the target names
ASSEMBLE := nasm -t ELF
BUILD := $(CC) $(CFLAGS) -c $@
LINK := $(CC) $(CFLAGS) -o $@

#### build rules
#############

all: dixium

dixium: kernel kbd tty
	$(LINK) $(OBJFILES)

kernel: boot.asm kernel.c
	$(ASSEMBLE) boot.asm
	$(BUILD) kernel.c

kbd: $(INCPATH)/kbd/kbd.c
	$(BUILD) $(INCPATH)/kbd/kbd.c

tty: $(INCPATH)/tty/tty.c
	$(BUILD) $(INCPATH)/kbd/tty.c

clean:
	del *.o
I'm comfortable with my existing batch which is not bash, it's similar but don't confuse it, please file.

Re: Why is ld complaining?

Posted: Mon Nov 21, 2016 9:22 am
by Schol-R-LEA
OK... just for the record, Makefiles aren't BASH scripts, they are their own thing. Make (which is actually a class of loosely related programs going back to before Unix was a thing, having first appeared around 1966, in ITS, I think; I know that the Unix utility was based on one of the same name in Multics) is a build automation tool, roughly equivalent of the 'project file' used in many IDEs, and do a lot of thing automatically that would take a fair amount of coding in most shell interpreters, including both DOS batch and BASH.

There are actually several build automation tools around, such as CMake, Bake, Automake, Meson, and Visual Build. Many languages have even more sophisticated build tools like Ant, Maven, NAnt, Gradle, Rake, SCons, and Leiningen.

However, if you are happy with what you have now, you certainly can stick with it.

Just out of curiosity, would you mind telling us what editor or IDE you use? If it is an IDE such as Visual Studio, Code::Blocks, or Eclipse, those generally have their own project file systems which can be used without any programming as all, at least for the program builds.

Re: Why is ld complaining?

Posted: Tue Nov 22, 2016 1:44 am
by NunoLava1998
Schol-R-LEA wrote:OK... just for the record, Makefiles aren't BASH scripts, they are their own thing. Make (which is actually a class of loosely related programs going back to before Unix was a thing, having first appeared around 1966, in ITS, I think; I know that the Unix utility was based on one of the same name in Multics) is a build automation tool, roughly equivalent of the 'project file' used in many IDEs, and do a lot of thing automatically that would take a fair amount of coding in most shell interpreters, including both DOS batch and BASH.

There are actually several build automation tools around, such as CMake, Bake, Automake, Meson, and Visual Build. Many languages have even more sophisticated build tools like Ant, Maven, NAnt, Gradle, Rake, SCons, and Leiningen.

However, if you are happy with what you have now, you certainly can stick with it.

Just out of curiosity, would you mind telling us what editor or IDE you use? If it is an IDE such as Visual Studio, Code::Blocks, or Eclipse, those generally have their own project file systems which can be used without any programming as all, at least for the program builds.
Notepad (seriously).
I'll change to Notepad++ right now.

Re: Why is ld complaining?

Posted: Tue Nov 22, 2016 10:43 am
by Schol-R-LEA
Meh, you don't have to change if you are comfortable with Notepad, it's just that it helps if we know what you're using so we can give more specific advice.

I would recommend looking at some of the options around (including Notepad++), just to get a feel for what they can do and which one feels best to you, but if you decide that Notepad is still your favorite, go with it. I use Emacs most of the time, but I still try out a lot of different editors and IDEs to see which ones have interesting features I haven't seen before.