Thema: GCC Funktionen in Header "undefined reference"

[LittleFox]

-lgcc an den Compileraufruf anhängen

[OS_3000]

Leider kommt dann "i586-elf-gcc: cannot find -lgcc".

[LittleFox]

äh - sorry
Linkeraufruf - hoff ich

Edit: Kommt davon wenn man auf Arbeit irgendwas postet

[kevin]

gcc -m 32 -print-libgcc-file-name sagt dir, wo sie liegt (falls sie installiert ist - ansonsten kann es sein, dass er dir die 64-Bit-Variante unterschieben will, die natürlich nicht funktioniert!). Diese .a-Datei übergibst du einfach mit an ld.

[OS_3000]

Ihr seit echt super, jetzt gehts! 
Bläht aber ein bisschen den Kernel auf. (8kb -> 40kb)

Gibt es eine Möglichkeit nicht immer den Pfad "C:\Programm Ordner\MinGW\OSprogramming\lib\gcc\i586-elf\4.4.0\libgcc.a" angeben zu müssen? Der ist nämlich höllisch lang und wenn ich das auf einen anderen Computer kompilieren will, muss er auch angepasst werden.

Sowas wie von LittleFox wäre gut.
Und ja, dass hab ich natürlich beim Linker angegeben. 

[Case23]

die Regeln bezüglich "inline" soweit ich es gerade im kopf habe:
1) niemals inline alleine verwenden, da die Sichtbarkeit (im Objectfile) von Funktionen dann abhängt vom Compiler und vom Optimierungslevel.
2) static inline sagt dem Compiler (genauso wie static alleine) das diese Funktion nicht sichtbar sein soll ausserhalb des generierten Objectfiles. Damit wird diese Funktion entweder geinlined, oder als eigene Funktion generiert, die aber nicht sichtbar ist nach aussen. Nachteil ist das wenn der Compiler in mehreren Objectfiles sich entscheidet die Funktion nicht zu inlinen, die Funktion mehrfach erzeugt wird (pro objectfile bis zu einmal) und dann auch mehrfach im executable ist.
3) extern static sagt dem Compiler dass er die Funktion entweder inlinen soll, oder sie als extern betrachten soll. Wenn man es so organisiert dass in allen C-Dateien als extern inline verwendet wird und in einer einzige als normale Funktion, wird genau in einem Objectfile die Funktion sichtbar sein (immer), und in allen anderen entweder geinlined oder als externe reference.
Beispiel zu 3:
inlineit.h:

Code: [Auswählen]

#ifdef INLINEIT_C
#define INLINEIT_INLINE
#else
#define INLINEIT_INLINE extern inline
#endif

INLINEIT_INLINE foobar() {
...
}
inlineit.c:

Code: [Auswählen]

#define INLINEIT_C
#include "inlineit.h"
anotherfile.c:

Code: [Auswählen]

#include "inlineit.h"

/*use foobar here*/


[kevin]

Gibt es eine Möglichkeit nicht immer den Pfad "C:\Programm Ordner\MinGW\OSprogramming\lib\gcc\i586-elf\4.4.0\libgcc.a" angeben zu müssen? Der ist nämlich höllisch lang und wenn ich das auf einen anderen Computer kompilieren will, muss er auch angepasst werden.

Ein Skript, das gcc -m32 -print-libgcc-file-name ausführt, zum Beispiel?

[OS_3000]

Ich wüsste nicht, wie ich das in einem Script machen soll.
Wahrscheinlich bist du Linuxumgebungen gewöhnt, da geht sowas wahrscheinlich.   

Zu Case23:
Dieses Problem hat sich eigentlich bereits geklärt. 
Was ich noch nicht so ganz verstanden hab ist, warum "extern static" immer geinlined wird.

[chris12]

Wenn du unter Windows bist ... was ich einfach mal dem Pfad aufbau entnehme ... dann kannst du einfach Batch nehmen, das ist auch eine scriptsprache ...

[OS_3000]

Natürlich, kann ich Batchdateien erstellen.
Doch darin kann man meines Wissens nicht die Ausgabe eine Programmes in eine MSDOS-Variable umleiten.

[kevin]

Hast du nicht eh MSYS installiert? Das hat doch eine bash?

[Jidder]

Makefile? Makefail! So setzt man unter Windows die Variable LIBGCC_FILE_NAME mit dem Dateinamen:

Code: [Auswählen]

FOR /F "usebackq" %%I IN (`gcc -print-libgcc-file-name`) DO SET LIBGCC_FILE_NAME=%%I
Ich unterwandere hier mal wieder alle Versuche die Leute zu guten Praktiken zu bewegen. 

[OS_3000]

MSYS? Nein

Code: [Auswählen]

FOR /F "usebackq" %%I IN (`gcc -print-libgcc-file-name`) DO SET LIBGCC_FILE_NAME=%%IFunktioniert fast.
Bloß wenn ein Leerzeichen im Pfad ist(wie bei mir ) dann bricht es ab.
Es liefert bei mir ledeglich "C:\Programm" zurück.


Wusste gar nicht, dass man sowas in MSDOS machen kann. 

[kevin]

Zu meinen Zeiten, als die Gummistiefel noch aus Holz waren, hatte for noch keine so komischen Parameter.

[OS_3000]

Nach ein bisschen rumprobieren, hab ich es jetzt hingekriegt. 

Code: [Auswählen]

FOR /F "usebackq tokens=*" %%I IN (`i586-elf-gcc -print-libgcc-file-name`) DO SET LIBGCC_FILE_NAME=%%I
Hätte nie gedacht, dass das mit der MSDOS-Stapelverarbeitung geht.
Nochmal vielen Dank für den genialen Tipp. 

[Jidder]

Viel Spaß damit. Übrigens ist das nicht für DOS sondern Windows NT.

[OS_3000]

Die Stapelverarbeitung läuft aber in einem MSDOS-Subsystem.

[Case23]

@OS_3000
static inline muss nicht inlinen, aber durch das static wird es auf jedenfall nicht sichtbar nach aussen

[OS_3000]

Upps...
Das ist dann wohl weniger für Standardlibs und Betriebssystemcalls geeignet. 
Also dann verwende ich "extern static".

EDIT: Ne auch nicht:
Bei "extern static" motzt der Compiler.
EDIT2: "extern inline" geht auch nicht.
Da motzt der Linker.

[Svenska]

Die Stapelverarbeitung läuft aber in einem MSDOS-Subsystem.

Nein, da Kommandozeile != DOS.
Du meinst COMMAND.COM, aber der kennt so fancy parameters nicht. Dafür brauchst du cmd.exe, eine echte WinNT-Anwendung.

PS: Beschaff dir eine UNIX-Umgebung. Bevorzugt mit einer unixoiden Basis. Das macht vieles einfacher.

So, nachdem die Haare hinreichend gespalten sind, geh ich schlafen.