warum macht der Linker underscores vor die Namen?

[Walter S. (avatar)]

ich versuche ein bestehendes C-Project unter xcode auf dem MAC zu bauen.
Der Compiler macht da aus irgendeinem Grund _ vor die Funktionsnamen und 
der Linker findet die dann nicht. Irgendwie hatte ich das schon Mal, es 
war irgendwas mit C und C++, habs aber vergessen wie man das umgeht.


Also in einem file der AUfruf
irgendwas(13);

in einem anderen File die Definition:
void irgendwas(int zahl) ...

und er Linker verlangt dann nach _irgendwas

[Bruno V. (bruno_v)]

Kümmer Dich nicht um den _. Ist nur zur Vermeidung von gleichen Namen 
C/Assembler.

Dem linker fehlt das (compilierte) File oder die lib, die die Funktion 
enthält. In C ohne _, im Assembler/Linker mit _.

[Walter S. (avatar)]

danke, ich probier morgen weiter

[Wilhelm M. (wimalopaan)]

Walter S. schrieb:
> Also in einem file der AUfruf
> irgendwas(13);
>
> in einem anderen File die Definition:
> void irgendwas(int zahl) ...
>
> und er Linker verlangt dann nach _irgendwas

Willst Du von C++-Code aus bspw. C-Funktionen aufrufen? Dann hast Du es 
mit dem Name-Mangling des C++-Compilers zu tun. Das müsstest Du für die 
C-Funktionsdeklarationen mit

extern "C" {
    int CFunction(void);
}

ausschalten.

[Harald K. (kirnbichler)]

Wenn der Linker solch einen Symbolnamen nicht findet, wird dem Linker 
nicht die Objektdatei übergeben, in der das Symbol definiert ist.

Oder das Symbol (hier: die Funktion "irgendwas") ist als static 
deklariert und ist daher nur innerhalb ihrer "translation unit" 
sichtbar.

Da der Linker _irgendwas sucht, wird diese Funktion auch nicht aus 
C++-Code heraus aufgerufen, denn deren Signatur sähe durch das "name 
mangling" entschieden anders aus.

Es könnte sein, daß die Funktion "irgendwas" aber als C++-Code übersetzt 
wurde, und daß der Aufrufer sie als C-Code aufrufen will, also genau 
andersherum als von Wilhelm beschrieben.

[Johann L. (gjlayde)]

Das zusätzliche "leading underscore" in Symbolnamen wird von manchen 
ABIs vorgeschrieben, d.h. ein Symbolname hat 1 Underscore mehr als auf 
anderen Plattformen.

So wird ein Object (Funktion oder Variable), das auf C-Ebene sym heißt, 
im Assembly als _sym ausgegeben. Beispiel C:

int var;

int fun (void)
{
    return var;
}

wird assembliert mit x686-w64-mingw32-gcc (unbedeutende Teile entfernt):

  .globl  _fun
_fun:
  movl  _var, %eax
  ret

  .globl  _var
  .bss
_var:
  .space 4

Und das gilt dann auch für C++:

fun wird in MinGW als __Z3funv assembliert, für x86_64-linux-gnu 
hingegen als _Z3funv.

Was unter MinGW auffällt, ist dass Labels zum Beispiel "L5" heißen, was 
ohne Underscore dann mit einem Objekt namens "L5" verwechselt werden 
würde. Das ABI vermeidet dies, indem Symbole von Hochsprache einen "_" 
verpasst bekommen.

Auf anderen Plattformen werden Labels z.B. als ".L5" benamt; keine 
Ahnung warum das unter Windows nicht gemacht wird / wurde.  Evtl. kann 
ein Archäologe da mehr zu sagen.

------------------------------------------------------------

Um in einem Project C und C++ zusamme zu nutzen müssen die C-Teile als 
extern "C" Linkage implementiert sein, im obigen Beispiel etwa

extern "C" int fun (void);

Um Assembly und C/C++ zusammen zu verwenden, muss im Assembly die Naming 
Convention dem ABI folgen.  Es ist zwar möglich, den Assembly Name mit 
GCC anzugeben, aber dabei wird man nach Möglichkeit dem ABI folgen, hier 
als GCC Erweiterung:

int fun (void) __asm ("_bar");

Schließlich gibt es je nach Host noch -f[no-]leading-underscore, aber 
was ABI angeht gilt das eben gesagte.