KPIT GNU C++ knas. Någon som kan förklara?

[Icecap]

OK, jag har startat ett projekt i KPIT GNU C (GCC) med C++-kompilern då jag gärna vill använda den pga. att den stödjer long long int.

Jag gör samma som de tidigare projekt: Inkluderar en massa filer i projektet, båda *.H och *.C.
Det finns RS232_A.h och RS232_A.c.
I RS232_A.c finns rutinerna för vad som ska hända med de olika funktioner (källkoden alltså) och i RS232_A.h finns det de vanliga referenser:
void RS232_A_Time_Tick(void);
void RS232_A_Initiate(_UWORD Baudrate);
osv.

I main-filen inkluderar jag "RS232_A.h" och borde då ha tillgång till de funktioner som är deklarerat i RS232_A.h filen. Men icke sa Nicke.
Använder jag C-kompilern (t.ex. C99) fungerar detta ypperligt så nu undrar jag över vad f.. som har ändrats.

Jag har testat att deklarera:
extern void RS232_A_Time_Tick(void);
extern void RS232_A_Initiate(_UWORD Baudrate);
extern osv.
i RS232_A.h-filen men det gjorde ingen skillnad.

Jag har såklart lagt in den vanliga:
#ifndef __RS232_A_H__
#define __RS232_A_H__

Definitionerna här.

#endif // __RS232_A_H__

Felmeddelandet kommer från linkern:
"Gas_Loading_100.cpp:(P+0xe53): undefined reference to 'RS232_A_Time_Tick()'"

Linkern inkluderar filer från projektbiblioteket och jag har verifierat att "RS232_A_Time_Tick" står med i object-filen.

Hade jag kallat fler funktioner hade det såklart varit fler fel men jag håller just på att starta projektet och anpassa hårdvarainterfacen.

EDIT: Om jag inkluderar de berörda *.C-filer istället för *.H-filerna fungerar det direkt - men det är ju fel då.

[sodjan]

Det låter ju som att den nödvändifa objectfilen inte länkas med.
Du har alltså en RS232_A.o (eller .obj eller vad det nu hter där)?
Och länkaren *ser* den vid länkningen?

[TomasL]

Kan vara sökvägsrelaterat.

[Icecap]

Jag har en .o fil, linkaren har den sökväg med i sina sökvägar. Har även lagt till rätt sökväg fastän det redan fanns med en korrekt sökväg.

Och det är ändå 4 filer så det känns som att den inte inkluderar dom allt.

Har testat att rensa alla filer och "fullkompilera" men det hjälpte inte heller. Ska testa att stänga ner IDE'n och starta om det.

Att jag har inkluderat alla filer i projektet beror på att om man editerar kommer alla filer som ingår i projektet att sparas automagisk strax innan kompileringen, något som inte sker om en fil används men inte är inkluderat i projektet.

[sodjan]

Kan du se hur IDE't har satt samman kommandot till länkaren?
Det brukar ofta synas i något "output" fönster...

Går det alltså att verifiera att rätt katalog kommer med?
Alltså inte bara att det finns med i någon dialog i IDE't.

Hjälper det (som en test) att flytta dina egna .o filer till
någon systemkatalog som du vet säkert kommer med?

[Icecap]

Har nu kollat och jämförd med ett fungerande C99-projekt och jag hittar ingen skillnader i gcc-filerna.

Inser att jag nog får återgå till C99 istället så jag kommer någonvart, den kompiler vet jag fungerar och den borde stödja long long-värden (64 bit).

Sedan när jag har bättre tid/mer lust får jag stånga mig blodig på C++. Kan misstänka att C++ kompilern inte är helt med men GCC borde ju vara rimligt OK med C++.

Vad jag kan se av TMP-filen är ordnen så att den tar in alla "undergivna" .O-filer (.OBJ) först innan den tar in main-filens .O-fil - så det borde vara rätt. Och det gäller i båda projekt.

Nåväl, det kan hänga ihop med att C++ per default använder "newlib" och inte de "optimerade", kanske jag ska testa att ändra just den bit bara.

EDIT: Näpp, inte det heller. Nej, jag skapar ett nytt projekt med C99 och "gamla" lib, det brukar fungera utan problem.

Mer EDIT: Jupp, efter att ha omdöbt biblioteket till något annat och skapat samma projekt igen men då med C99 istället för C++ kompilerar det utan problem i första försök. Jag måste nog läsa på om C++ fungerar alls och jag ska definitivt se om jag kan lägga in C99 som standardval vid skapande av nya projekt.

[sm5tfx]

C++-kompilatorn kommer att mangla namnen enligt ABI-standard (förhoppningsvis), d.v.s. så att parameter- och returtyper ingår in symbolen.
G++ 4.8.1 på Linux/x86_64 kommer t.ex att mangla void foo() till _Z3foov.

Patentlösningen är att lägga en extern "C" omkring deklarationerna i .h-filen:

Kod: Markera allt

#ifdef __cplusplus
extern "C" {
#endif
void foo();
#ifdef __cplusplus
}
#endif

EDIT: fixade koden.

[sodjan]

Du kompilerar allting alltså med samma C++ kompilator?
Jag har för mig att C++ mixtrar lite mer referenserna/namnen
på saker och ting, lite osäker här dock...

> Att jag har inkluderat alla filer i projektet...

Det är väl även en förutsättning för att de automatiskt genererade
"make" filerna ska fungera. Så är det normalt i alla fall.

EDIT:
Alltså något i stil med det som sm5tfx skriver. Men å andra sidan,
om allt är kompilerat med samma kompilator så borde det väl i alla
fall fungera med samma "mangling" i båda ändar så att säga. Det var
därför som jag frågade om alla delar var körda genom samma kompilator.

[Icecap]

Tack för svaren. Jag ska tugga mer på detta när jag får tid men just nu är det funktion som gäller.

Och det jag vill uppnå, alltså att kompilern kan jobba med 64-bit värden skulle vara fixat med C99 så jag är som sådan i mål. Men att kunde jobba med C++ är ju inte fy-skam, speciellt inte när jag har ett kretskort som ska uppfylla fler olika funktioner, då kunde klasser osv. vara trevliga att kunde lägga in.

Men nu får det vara slut på dagen, jag är alldeles virrig av trötthet.

[sm5tfx]

Men å andra sidan, om allt är kompilerat med samma kompilator så borde det väl i alla fall fungera med samma "mangling" i båda ändar så att säga.

Ja, men GCC i C-mod är inte "samma kompilator" som GCC i C++-mod. Bland annat just eftersom olika regelverk för namnmanglingen gäller i C++ jämfört med i C , även på samma plattform.

Engelska wikipedia om Name Mangling.

EDIT: om man använder gcc som kopileringskommando så kommer den att gå i C-mod för filer med suffix .c och i C++-mod för filer med suffix .C, .cc, .cxx och .cpp (jag är inte helt säker på de två sista) - OM man inte anger något annat med --std=-parametern eller motsvarande.

[sodjan]

Nej, självklart...
Men nog skulle det väl fungerar med funtionen
och main kompilarede i samma "mode"? Annars
skulle det ju dels alltid vara problem, dels finnas
en annan lösning på det en extern "C" hacket...

[sm5tfx]

I det ursprungliga exemplet kommer RS232_A.c att kompileras som C-kod och Gas_Loading_100.cpp att kompileras som C++ (under förutsättningen att miljön eller byggsystemet inte gör nåt special). Deklarationerna i RS232_A.h säger inget om vilket vilken namnkonvention som skall användas och därmed kommer olika namn att genereras och användas för det som är tänkt att vara samma funktion.

På mitt system här (enligt ovan) genererar C++-kompilatorn en odefinierad referens till _Z17RS232_A_Time_Tickv
medan C-kompilatorn genererar en funktion med namnet RS232_A_Time_Tick när jag kompilerar kod motsvarande exemplet i trådstarten.

extern "C" 'är inget hack utan avsett att lösa just detta (och besläktade) problem. En annan variant är att kompilera all egen C-kod med C++-kompilatorn, det går för det mesta bra om ingen varit alltför uppfinningsrik. Jag tycker dock att det är mer av ett hack.

EDIT: kör nm utan -C på respektive objektfil så ser du vilka namn som faktiskt genererats. gcc eller g++ -S kan också vara informativt.

EDIT2: naturligtvis kan man lägga extern "C"-blocket omkring inkluderingen också, fast det kan generera en del intressanta problem beroende på vad header-filen innehåller.
Alltså:

Kod: Markera allt

// i program.cc
extern "C" {
#include "c-header.h"
}

[sodjan]

Ah, just det ja, det var ju olika extension på filerna! Så klart...

Då är jag helt med, det är ju bara helt vanlig anpassning
då man kombinerar olika språk. Då är jag helt med...

> ...genererar C++-kompilatorn en odefinierad referens till _Z17RS232_A_Time_Tickv

Ja, den generar en referens, men det är först vid länkningen som den blir odefinierad...
Sen så kan vissa länkare visa symbolen "un-mangled", om jag har förstått rätt.
Det gör det lite svårare att se och det kan ju vara så i Icecaps fall...

[Icecap]

I grunden betyder detta att om jag vill köra med C++ måste jag döpa om filerna till att ha .CPP hhv. .HPP på slutet istället för .C hhv. .H.

Detta skulle betyda att jag antingen måste gå igenom alla gamla projekt och konvertera dom till C++ eller underhålla dubbla uppsättningar filer med identisk innehåll - och då vinner C alla gångar! Det fungerar per definition inte att ha dubbla filer med samma innehåll

Jag ska - vid tillfälle - testa att kopiera filer och göra ett "riktigt" C++ projekt för att se om det gör en skillnad, dock sorterar IDE't de inkluderade filer som C hhv C++ typer.

Men för min del vinner jag inget med C++ om jag använder C99 som kompiler för C-projekt så det får vara, jag har ett fungerande filsystem som enkelt medger att jag får projekt att fungera snabbt och säkert, hittar jag fel i någon fil eller bättrar på en funktion kommer förbättringen automagisk att ske nästa gång jag kompilera ett projekt och det får duga.

[Nerre]

Du borde väl kunna använda det där extern "C" istället?

Alltså

Kod: Markera allt

extern "C" void RS232_A_Time_Tick(void);

om jag fattat rätt.

Då förstår C++-kompilatorn att det är en header-fil från ett C-program och manglar den på "rätt" sätt.

Eller som det beskrivs här (med #ifdef i .h-filerna) http://elektronikforumet.com/forum/view ... 7#p1102537