Thema: GNU ld

[Tbex]

Guten Tag

Ich habe mir einen neuen Laptop gestern gekauft und wollte alle Programme die ich für mein OS brauche installieren.

Nachdem ich alles installiert habe wie auf meinem alten Rechner bekomme ich folgende Meldung wenn ich make ausführe:

....
ld -T kernel.ld .....
GNU ld version 2.13
...
using internal linker script //obwohl oben -T steh :/

gleiche files auf dem alten benutzten kommt dies:
...
using external linker script
....

bin ein bisschen ratlos, habe es so installiert wie damals auf dem alten rechner
einzifer unterschied ist, das der neuer rechner win 8 hat und nicht 7

[OsDevNewbie]

Wie siehts aus wenn du anstatt "ld -T kernel.ld" "ld --script=kernel.ld" verwendest?

[Svenska]

Du solltest zum Linken nicht ld direkt aufrufen, sondern besser gcc benutzen. Tritt das Problem dann auch noch auf?

Die GNU-Tools unter Windows sind immer so eine Sache. Benutzt du cygwin, MinGW oder etwas anderes?

[Tbex]

Mit "ld --script=kernel.ld" geht es Vielen Dank!

@Svenska, wie meinst du nicht direkt aufrufen?
Ich habe eine Batch Datei die das Makefile ausführt.

Ich benutzt zurzeit noch djgpp, da dieses tool im tut von henkessoft am Anfang benutzt wird.
Ich werde aber irgendwann auf eine cross-Compiler umsteigen müssen(dürfen).

Ist dies gut oder soll ich direkt auf was anderes umstellen?

[Svenska]

Hier ein Beispiel, was mein Makefile aufruft (ist allerdings für einen ARM-Controller, was anderes hab ich gerade nicht da):

Code: [Auswählen]

CFLAGS = -mcpu=cortex-m3 -mthumb -mfloat-abi=soft \
    -ffunction-sections -fdata-sections -fno-common -g -std=gnu99 -Wall -Wextra -Os -I.
LFLAGS = -static -nostartfiles -lc -lgcc -specs=nano.specs -Wl,--gc-sections

# kompilieren
arm-none-eabi-gcc $(CFLAGS) -c -o startup.o startup.c
arm-none-eabi-gcc $(CFLAGS) -c -o syscalls.o syscalls.c
arm-none-eabi-gcc $(CFLAGS) -c -o main.o main.c
arm-none-eabi-gcc $(CFLAGS) -c -o uart.o uart.c
arm-none-eabi-gcc $(CFLAGS) -c -o display.o display.c

# linken
arm-none-eabi-gcc -Tlm3s811.ld $(CFLAGS) $(LFLAGS) -o main.elf startup.o syscalls.o main.o uart.o display.o

Ich benutze gcc also sowohl für das Kompilieren der einzelnen C-Dateien (übrigens auch für das Assemblieren der S-Dateien), als auch für das Linken der Objekte zum Endergebnis.

Da ich kein Windows benutze, kann ich dir leider nicht sagen, was die beste Toolchain (oder welche Version) dafür ist. Aber es kann gut sein, dass das ein Fehler (oder eine Eigenheit) von DJGPP ist. Am Anfang spielt die Toolchain keine große Rolle, später solltest du sowieso auf einen Crosscompiler umsteigen. Ich benutze Linux und würde dir eine virtuelle Maschine empfehlen, aber MinGW oder Cygwin sollten's auch tun.

Gruß,
Svenska

[kevin]

DJGPP ist ja nichtmal ein Windows-Compiler, sondern ein DOS-Compiler, der meines Wissens schon immer (auch dem Ziel-OS geschuldet) ein paar Eigenheiten hatte. Ich persönlich würde den nicht für OS-Dev benutzen wollen. Nicht weil's nicht geht, sondern eher aus dem unbestimmten Gefühl heraus, dass da ständig irgendwas unerwartetes kaputt sein könnte, weil ein DOS-Compiler heutzutage sowieso wenig getestet wird und für sowas wie OS-Dev halt im Allgemeinen gar nicht benutzt wird.

Aber ich würde auch einen Haufen andere Sachen anders als Erhard machen, was sich auch darin ausdrückt, dass unsere Tutorialreihe auf Lowlevel etwas anders vorgeht.