Forum: Compiler & IDEs Ärger mit Codeblocks


von Gerhard H. (oderlachs)


Lesenswert?

Hallo Freunde !
Ich habe schon im Web recherchiert, im Forum hier gelesen, aber so 
richtig habe ich keine Lösung gefunden.
Da ich mich ja nun mal unter Linux auf eine Entwicklungsumgebung (für 
C,C++, AVR u. evt. Arduino) festlegen möchte, habe ich mir mal das 
vielversprechende Code-Blocks installiert.

Aber schon bei einer einfachen Linux_PC Anwendung stehe ich schon vor 
einem Phänomen.

Ich habe 3 Dateien erstellt, über die includierte Headerdatei, soll die 
CPP-Main-Datei eine Routine in der 2. CPP Datei nutzen.

Ich bekomme es nur hin wenn ich die *.cpp Datei mit einbinde, aber nicht 
wenn nur die Headerdatei eingebunden wird.

Hier mal der der Code, zum Erlernen von CB sehr einfach gehalten:
1
//**************************************
2
//main.cpp
3
//**************************************
4
#include <iostream>
5
#include "ol_cpp_hd.h"
6
//#include "ol_cpp_hd.cpp"  // >> nur dann geht es
7
using namespace std;
8
9
int main(void)
10
{
11
    print_vCard();
12
    return 0;
13
}
14
//**************************************
15
//ol_cpp_hd.h
16
//**************************************
17
#ifndef OL_CPP_HD_INCLUDED
18
#define OL_CPP_HD_INCLUDED
19
20
//vCard definitionen
21
#define Name    "Otto Mustermann\n"
22
#define Firma   "Musterfirma \n"
23
#define Ort     "Musterberg/Mark\n"
24
#define Strasse "Waldegger-Platz\n"
25
26
27
void print_vCard();
28
29
#endif // OL_CPP_HD_INCLUDED
30
31
//**************************************
32
// //ol_cpp_hd.cpp
33
//**************************************
34
#include <iostream>
35
#include "ol_cpp_hd.h"
36
using namespace std;
37
38
void print_vCard(void)
39
{
40
    cout << Name << Firma<<Ort<<Strasse;
41
42
}

Hier der Build Log, das die Function  print_vCard unbekannt ist:


-------------- Build: Release in CppTest_1 (compiler: GNU GCC 
Compiler)---------------

g++  -o bin/Release/CppTest_1 obj/Release/main.o  -s
obj/Release/main.o:
In Funktion `main':
main.cpp:(.text.startup+0x5): Nicht definierter Verweis auf 
`print_vCard()'
collect2: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))



Kann mir vielleicht bitte jemand einen Hinweis geben, was ich da falsch 
mache ??
Kenne mich mit den internen Gepflogenheiten von Code-Blocks noch nicht 
so aus..
Die Probleme bei AVR Programmierung  möchte ich hier noch nicht 
ansprechen, vielleicht bekomme ich das ja noch selbst hin.

Es geht mir hauptsächlich darum, ein Projekt aus mehreren Dateien fertig 
zu bekommen.

Gruss und Danke

Gerhard

von Felix U. (ubfx)


Lesenswert?

Gerhard H. schrieb:
> das vielversprechende Code-Blocks

Da müssen wir aber von verschiedenen Code-Blocks reden ;)

Hast du deine Dateien zu einem Projekt hinzugefügt? Wenn nicht, dann 
wird nur die gerade geöffnete Datei kompiliert.

: Bearbeitet durch User
von Gerhard H. (oderlachs)


Lesenswert?

Ja Felix,


natürlich habe ich die in EINEM Projekt erstellt. Sonst hätte das ja 
keinen Sinn.

Darum ist es mir ja so Paradox, weil ich ja auch einzelne Dateien aus 
dem Projekt "entfernen" kann.
Aber wie gesagt ist mein erster Einstig mit Code::Blocks, wo ich nicht 
nur "Hallo Welt" programmiere ;)

Nun ja, auch hängt mein täglich Brot nicht davon ab, aber man will's 
doch auch wissen, warum es nicht geht, wenn's auch nur fürs Hobby ist.

Kann ja sein das die Linux-Ausgabe wieder ein paar Bugs an Board hat.
AVR geht ja auch nicht damit, aber das ist erst mal noch Nebensache.

Mir stört es nur immer mal wieder zwischen Linux und Win umher 
zuspringen.
Darum wollte ich alles was Programmierung betrifft auf Linux aufbauen.

Gerhard
Nachtrag:

Nun geht es ich habe "ol_cpp_hd.cpp" aus dem Projekt entfernt und neu 
hinzugefügt, das war es.
Wer weiss, ob irgendwo ein Byte geklemmt hat, oder ein Bug in der Linux 
Ausgabe ist.

: Bearbeitet durch User
von Rainer V. (rudi994)


Lesenswert?

Hier in Win7 ähnlich, Fehler "Mehrfache Deklaration von 
'print_vCard()'", wenn ol_cpp_hd.cpp gleichzeitig sowohl in main.cpp 
inkludiert als auch im Projektmanager aufgeführt wird. Keine Fehler in 
folg. Fällen:
- mit #include "ol_cpp_hd.cpp", aber kein ol_cpp_hd.cpp im 
Projektmanager.
- ohne #include "ol_cpp_hd.cpp", aber ol_cpp_hd.cpp im Projektmanager.
- ol_cpp_hd.cpp in ol_cpp_hd.hpp umbenennen und die hpp-Datei 
inkludieren, letztere darf im Projektmanager aufgeführt sein, muß es 
aber nicht.

Manche Fehler werden mögl.weise auch bereinigt, wenn man im Menü nicht 
"Build" auswählt, sondern mit "Rebuild" alles neu compiliert. LG

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Rainer V. schrieb:
> wenn ol_cpp_hd.cpp gleichzeitig sowohl in main.cpp
> inkludiert
.cpp Dateien werden nicht includiert!

von Gerhard H. (oderlachs)


Lesenswert?

Vielen Dank für Eure Bemühungen !

Ja ich weiss auch nicht, ich habe gelernt in der Main-Datei wird die 
Headerxx.h includiert usw.
Nun bin ich nach 3 Versuchen mit Code-Blocks damit noch nicht so 
Programm-Intern versiert , um zu wissen ob das dann reicht bzw auch 
richtig ist. Beim Erstellen der Dateien werden ja schon im Manager(?) 
die Dateien dem Project zugefügt oder nicht.
Nun könnte eine Warnung wegen doppelte Includierung kommen, aber das 
soll ja in der headerxx.h durch
1
 #ifndef _HEADER_XX_H_
 usw vermieden werden.

Bei mir wird da auch in der Richtung nichts reklamiert, nur das eben auf 
Funktionen usw. in der anderen xx.cpp nicht zugegriffen werden kann, 
obwohl die Prototypen der Funktionen in der headerxx.h zur Verfügung 
stehen.

Ich werde das am Wo-Ende mal unter Windows und Code-Blocks probieren, 
vielleicht mache ich ja auch einen grundlegenden Fehler.


Gerhard

von Detlev T. (detlevt)


Lesenswert?

Gerhard H. schrieb:
> g++  -o bin/Release/CppTest_1 obj/Release/main.o  -s
> obj/Release/main.o

Warum auch immer. Mit dieser Zeile soll nur(!) main.o zu CppTest1 
gelinkt werden. Die Objektdatei xx.o fehlt - und damit auch alle 
Implementierungen aus ihr.

Die Konfiguration des Projekts ist also fehlerhaft. Deswegen kommt die 
Fehlermeldung auch vom Linker (ld) und nicht vom Compiler:

Gerhard H. schrieb:
> collect2: error: ld returned 1 exit status

von Hmmm (Gast)


Lesenswert?

Gerhard H. schrieb:
> Beim Erstellen der Dateien werden ja schon im Manager(?) die Dateien dem
> Project zugefügt oder nicht.

Beim Erstellen eines neuen Files kommt eine Abfrage, ob es ins Projekt 
soll. Wenn ja, muss man es erstmal speichern und noch die Build-Targets 
ankreuzen.

von Rainer V. (rudi994)


Lesenswert?

Kaj G. schrieb:
> .cpp Dateien werden nicht includiert!

Ja, habe ich auch gedacht, funktioniert aber bei CodeBlocks 13.12 mit 
MinGW32 3.2 und ist möglicherweise auch nicht streng verboten. Fehler 
treten bei mir nur dann auf, wenn o.g. Dateien in einem CodeBlocks 
Projekt (hier: Console-App) verwendet werden und ol_cpp_hd.cpp sowohl 
mit #include eingebunden als auch gleichzeitig im Projektmanager 
aufgeführt wird. Dann wird außer main.o auch eine ol_cpp_hd.o erzeugt, 
was vermutl. (beim Linken) zum Fehler "Mehrfache Deklaration von 
'print_vCard()'" führt. Ist diese Funktion als static deklariert, so 
tritt dieser Fehler nicht auf, jedoch der Fehler, daß die Funktion 
deklariert ist, aber nicht verwendet wird.

Außerhalb eines Projektes treten keine Fehler auf und es wird nur main.o 
erzeugt. Datei ol_cpp_hd.cpp alleinstehend ist nicht compilierbar, da 
sie keine Funktion main() enthält, weshalb auch kein Konsolenfenster 
erzeugt werden kann (Fehler: undefined reference to 'WinMain@16').

Btw, habe mal gelesen, daß Code wie oben als *.hpp inkludiert werden 
soll bzw. der Code in *.h und *.hpp aufgeteilt, reine Header-Anteile in 
*.h, z.B. Definitionen von Konstanten und Typen, Vorwärtsdeklarationen 
von Funktionen (Funktionsprototypen). Der Rest kommt in *.hpp, z.B. die 
komplette Funktionsdefinition (Kopf und Rumpf).

: Bearbeitet durch User
von Hmmm (Gast)


Lesenswert?

Rainer V. schrieb:
> Kaj G. schrieb:
>> .cpp Dateien werden nicht includiert!
>
> Ja, habe ich auch gedacht, funktioniert aber bei CodeBlocks 13.12 mit
> MinGW32 3.2 und ist möglicherweise auch nicht streng verboten.

Theoretisch kannst Du alles includen, aus Sicht des Compilers hast Du 
dann ein Riesen-Source-File.

Aber das ist extrem schlechter Stil, und man handelt sich damit Probleme 
ein, z.B. Namenskonflikte trotz "static".

von Dumdi D. (dumdidum)


Lesenswert?

Codeblocks macht es richtig. Man muss entweder die Obhektdateien linken 
oder die .cxx inkludieren. Aber nicht beides. Wenn die Datein ins 
Projekt genommen werden werden sie gelinkt. Wenn man nur  die Hauptdatei 
compiliert werden keine anderen automatisch gelinkt (Kommandozeile).

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Dumdi D. schrieb:
> Codeblocks macht es richtig. Man muss [...] die .cxx inkludieren.
Nein! Einfach nein.

von Markus F. (mfro)


Lesenswert?

Kann man schon so machen.

Aber dann isses halt Kacke ...

von Dr. Sommer (Gast)


Lesenswert?

Gerhard H. schrieb:
> #ifndef _HEADER_XX_H_

Vorsicht, selbst definierte Bezeichner dürfen nicht mit Unterstrich + 
Großbuchstabe oder doppeltem Unterstrich anfangen (reserviert für die 
Standard Library) .

von dumdidum nicht angemeldet (Gast)


Lesenswert?

Kaj G. schrieb:
> Dumdi D. schrieb:
>> Codeblocks macht es richtig. Man muss [...] die .cxx inkludieren.
> Nein! Einfach nein.

Naja, da hast Du recht; es ging mir darum dem TE klarzumachen warum die 
Kommandozeile kompiliert. Ich dachte, das geht aus dem vollständigen 
Satz einigermaßen hervor. (Vom Handy tippt es sich so schlecht 
ausführlich)

von Gerhard H. (oderlachs)


Lesenswert?

Hallo Freunde !

Menno, da habe ich ja eine Diskussion losgetreten  ;)

Kann aber mit Entfernen der xx.cpp und wieder hinzufügen zum Projekt , 
das Problem beheben, etwas umständlich, aber es geht.

Viel mehr Ärger macht mir CB und der ARM Compiler, den CB nicht finden 
will.
Aber das ist wohl ein anderes Glas Bier, was hier nicht her gehört.

Vielleicht liegt auch alles an dem etwas Entwickler unfreundlichen 
Linux-Mint.

Nun gönnt Euch erst einmal heute einen ruhigen Sonntag und vielen Dank

Gerhard

von Nop (Gast)


Lesenswert?

Gerhard H. schrieb:

> Viel mehr Ärger macht mir CB und der ARM Compiler, den CB nicht finden
> will.

Wie, "finden"?! Den mußt Du wohl mal einstellen. Das ist auch gut so, 
weil man ja den Compiler mehrfach in verschiedenen Versionen installiert 
haben kann, oder auch für verschiedene Plattformen. Da mußt Du schon 
sagen, welches der gewünschte sein soll.

von Gerhard H. (oderlachs)


Lesenswert?

Hier meine Einstellungen:

http://oderlachs.de/ARM/Pictures/einstellungen.png

manuell eingetragen .

Will ich ein ARM Project erstellen ...kein Compiler:

http://oderlachs.de/ARM/Pictures/kein_compiler.png

CodeBlocks Ver. 13.12, Linux Mint 18.1, 64-Bit

I

Gruss Gerhardch fass mich nur noch an den Kopf , ob noch ein paar graue 
Haare drauf sind... ;)

von cross compiler (Gast)


Lesenswert?

Das Problem sitzt 45cm vorm Bildschirm.
Beim Crosscompile musst du das Environment richtig setzen. CodeBlocks 
nutzt nur die Environmentariable und der Entwickler stellt auf seinem 
System den gewünschten Compiler ein. Das ist Entwickler freundlich! Aber 
nichts fuer Ottos. :-P :-P :-P

von Nop (Gast)


Lesenswert?

cross compiler schrieb:
> CodeBlocks nutzt nur die Environmentariable und der Entwickler
> stellt auf seinem System den gewünschten Compiler ein.

Wie funktioniert das eigentlich, wenn man dasselbe Projekt mit 
verschiedenen Compilern durchziehen möchte?

von Hmmm (Gast)


Lesenswert?

Gerhard H. schrieb:
> Hier meine Einstellungen:
>
> http://oderlachs.de/ARM/Pictures/einstellungen.png
>
> manuell eingetragen .

Das "/bin" am Ende muss weg, wie direkt darunter beschrieben.

von cross compiler (Gast)


Lesenswert?

Nop schrieb:
> dasselbe Projekt mit
> verschiedenen Compilern durchziehen möchte

Im Verzeichnis vom gcc steht i. d. R. nur ein Link auf die gewünschte 
Verison. Den kannst du einfach umbiegen.

Bei unterschiedlichen Plattformen nimmst dur ARCH=...

Und natürlich alles mit script und/oder Makefile. ;-)

von Gerhard H. (oderlachs)


Lesenswert?

cross compiler schrieb:
> Das Problem sitzt 45cm vorm Bildschirm.
> Beim Crosscompile musst du das Environment richtig setzen. CodeBlocks
> nutzt nur die Environmentariable und der Entwickler stellt auf seinem
> System den gewünschten Compiler ein. Das ist Entwickler freundlich! Aber
> nichts fuer Ottos. :-P :-P :-P

Ich glaube schon, das ich das Problem bin, vielleicht auch in Deinen 
Augen ein "Otto", aber das erlaubt mir doch hier zu fragen, ob mir 
vielleicht bitte wer erklären kann, was ich falsch mache ???

Aber wenn man bislang auf dem Gebiet ARM & CodeBlocks noch nicht 
gearbeitet hat, ist doch wohl Fragen erlaubt ?

Wenn nicht, so möchte ich dieses Thema als beendet ansehen..

Gruss und Dank

Gerhard

von Nop (Gast)


Lesenswert?

cross compiler schrieb:

> Im Verzeichnis vom gcc steht i. d. R. nur ein Link auf die gewünschte
> Verison. Den kannst du einfach umbiegen.

Auch nicht gerade das, was ich unter "komfortabel" verstehen würde.

> Bei unterschiedlichen Plattformen nimmst dur ARCH=...

Und dann muß man das jedesmal auf der Kommandozeile setzen und 
Codeblocks neu starten?!

> Und natürlich alles mit script und/oder Makefile. ;-)

Die Frage ging aber um CB und nicht um makefiles.

von Michael W. (Gast)


Lesenswert?

Felix U. schrieb:
> Gerhard H. schrieb:
>> das vielversprechende Code-Blocks
>
> Da müssen wir aber von verschiedenen Code-Blocks reden ;)

Ist das dieses http://www.codeblocks.org/

von Gerhard H. (oderlachs)


Lesenswert?

Ja das ist es !!!
Nur habe ich als Systeminstallation unter Linux Mint die Vers. 13.12 !

http://oderlachs.de/ARM/Pictures/codeblocks.png

http://oderlachs.de/ARM/Pictures/projektstart.png

Installiere ich "per Hand" die Vers. 16.01 kann ich bei einem ARM 
Projekt erstellen, nur ARM Entwicklerbords aufrufen, die ich gar nicht 
besitze
und nicht etwa einen STM32Fxxx programmieren.

Ich werde mal alles was STM ist in die Tonne hauen und bei AVR und PIC 
bleiben, ich glaub das wär sinnvoller für mich


Gerhard

: Bearbeitet durch User
von Gerhard H. (oderlachs)


Lesenswert?

Möchte noch was nachtragen ,
mir geht es  erst einmal darum folgendes programmieren zu können:
STM32F0-Discovery Bord, ein STM32F103 MiniBoard, eventuell noch das STm8 
Discovery Bord.

Vieleicht gibt es ja andere Möglichkeiten....aber bitte nicht im 
Konsolen Modus, das möchte ich wegen der kranken Finger nicht.

Gerhard

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.