Linkerproblem - C Code in C++ Code linken

[C. M. (chrisliebaer)]

Hallo zusammen,

ich habe folgendes Problem:
Ich habe noch nicht viel mit dem GCC auf der AVR Plattform gearbeitet 
und bin mir daher nicht sicher ob das Problem an mir liegt, oder ob ich 
da villeicht gerade in einer noch nicht implementierten Sparte vom GCC 
rumstochere.

Es gibt eine main.cpp mit folgendem Inhalt

#include <io/uart.h>

int main()
{
  debugInit(9600);

}

Die Datei wird also mit g++ kompiliert. Das ist auch notwendig, also 
bitte keine Hinweise, dass ich einfach mit dem gcc kompilieren soll, ich 
brauch später C++.

Nun bau ich mir gerade eine Library für einige Funktionen, wie z.B. 
Initialisierung fürs UART; linke also diese dazu

Dort gibts es dann folgende Datei io/uart.c:

//[..]
void debugInit(unsigned pBaudRate)
{
  setDebugBaudRate(pBaudRate);
  
  //enable transmitter/receiver register
  UCSR0B |= 1 << TXEN0;
  UCSR0B |= 1 << RXEN0;
  
  //set frame format: 8data, 1 stop bits
  UCSR0C = (1 << USBS0) | (3 << UCSZ00);
  
  stdout = &mystdout;
}
//[..]

Und dazu natürlich noch die Header Datei:

#pragma once

#include <inttypes.h>
#include <stdio.h>

void debugInit(unsigned pBaudRate);
//[..]

Dies wird mit dem GCC kompiliert, also kein C++ an dieser Stelle.

Das problem ist nun, dass der Linker bei obigen Code motz, dass er 
debugInit(unsigned pBaudRate); nicht linken konnte.

Kompiliere ich die main.cpp als C Code geht es.

Hat da jemand eine erklärung für? Ich finde einfach meinen Fehler nicht 
und bin auch nicht sicher ob es nicht villeicht sogar ein Problem mit 
dem Linker an der stelle gibt, wenn C mit C++ geklinkt wird. Wobei das 
ja eigentlich egal sein müsste, da der Code zu diesem Zeitpunkt ja 
bereits kompiliert ist.

Vielen Dank schonmal

Gruß
Chris

[Klaus W. (mfgkw)]

#include <inttypes.h>
#include <stdio.h>

#ifdef  __cplusplus
extern "C" {
#endif

void debugInit(unsigned pBaudRate);
//[..]

#ifdef  __cplusplus
}
#endif

In der io/uart.c muß natürlich auch die .h #includet werden.

[Hmmmm (Gast)]

Chris R. schrieb:
> Das problem ist nun, dass der Linker bei obigen Code motz, ...

Das ist keine Fehlermeldung. Die selbige wäre aber interessant.

[C. M. (chrisliebaer)]

Erstmal vielen Dank für die Idee mit dem eingebetteten C Code, auf die 
Idee bin ich garnicht gekommen, aber das ist ja auch keine Erklärung für 
das Problem, sondern nur ein Workaround.

Fehlermeldung vom Kompiler:

./main.o: In function `main':
main.cpp:(.text+0x4): undefined reference to `debugInit(unsigned int)'

[Hmmmm (Gast)]

Klaus Wachtler schrieb:
> #ifdef  __cplusplus
> extern "C" {
> #endif

Ist das nicht die Lösung, wenn man 'C' Code aus 'C++' heraus aufrufen 
will?
Der TO möchte genau das andere, aus 'C++ ' eine 'C' Funktion aufrufen.
Aber vielleicht hilft es in beiden Fällen, weiß ich gerade nicht.

[Klaus W. (mfgkw)]

PS: include-guards statt #pragma... wäre portabler:

#ifdef _IO_UART_H_
#define _IO_UART_H_

#include <inttypes.h>
#include <stdio.h>

#ifdef  __cplusplus
extern "C" {
#endif

void debugInit(unsigned pBaudRate);
//[..]

#ifdef  __cplusplus
}
#endif

#endif /* ifndef _IO_UART_H_ */

[Klaus W. (mfgkw)]

Hmmmm schrieb:
> Klaus Wachtler schrieb:
>> #ifdef  __cplusplus
>> extern "C" {
>> #endif
>
> Ist das nicht die Lösung, wenn man 'C' Code aus 'C++' heraus aufrufen
> will?
> Der TO möchte genau das andere, aus 'C++ ' eine 'C' Funktion aufrufen.
> Aber vielleicht hilft es in beiden Fällen, weiß ich gerade nicht.

Ich nehme an, daß seine (mir unbekannten Fehler) davon kommen, daß bei 
C++ per default name mangling stattfindet.
Dann wird in seiner CPP-Datei also aus dem Funktionsnamen n der .h etwas 
anderes gemacht, als wenn er die andere Datei mit C kompiliert.

dagegen hilft, die C-Funktionen als extern "C" zu deklarieren.
Nötig ist es also hier in jedem Fall; ob es alle seine Probleme löst muß 
man abwarten.

[Klaus W. (mfgkw)]

Chris R. schrieb:
> aber das ist ja auch keine Erklärung für
> das Problem, sondern nur ein Workaround.

Dieser Workaround ist gängige Praxis.

[Rolf M. (rmagnus)]

Klaus Wachtler schrieb:
> Chris R. schrieb:
>> aber das ist ja auch keine Erklärung für das Problem, sondern nur ein
>> Workaround.
>
> Dieser Workaround ist gängige Praxis.

Außerdem ist dieser Workaround kein Workaround, sondern der dafür 
vorgesehene Weg.