|
| Header-fil problemer... Fra : Torben Wridt |
Dato : 10-05-01 07:57 |
|
Hej!!
Er ny her i NG, og starter op med et sikkert noget "dumt" spørgsmål, hi.
Har igennem flere år brugt et kit fra fa. Velleman som hedder K-8000. Det er
et elektronik-modul som drives via en LPT-port og som indeholder 16 digitale
kanaler, og et antal analoge AD'ere og ditto DA'ere. "Hemmeligheden" er så,
at signalerne fra printerporten "konverteres" til en IIC-bus.
Til at foretage den egentlige timing etc. af denne bus medleverer Velleman
bl.a. en unit-fil til Pascal-folk, og en header-fil til C-folk. Har indtil
dato brugt modulet i.forb. med Pascal-programmer, men fandt det mere
"fremtidssikkert" at konvertere til C!!
Og så startede mine problemer....Har ikke før selv skrevet endsige
implementeret "fremmede" include-filer!
Den medfølgende "I2C.C" har jeg compilet med compilerens(en "gammel" version
3) "library"-funktion. De derved generede I2C.lib og I2C-obj filer har jeg
smidt ind i compilerens "library"-dir. Den medfølgende header-fil, som
hedder I2C.h er placeret i "header"-dir. (Matcher naturligvis compilerens
opsætning mht. dirs)
Med kittet er der en hel del demo-software. Problemet er, at jeg ikke kan få
disse eksempler til at funke. Compileren fejl-melder, at den ikke kan finde
de funktionskald som er indeholdt i headerfilen.....
Æhhh......, hvad gør JEG forkert????
Håber ikke, at mit spørgsmål er alt for dumt. Bær over med mig...
Venligst Torben W.
| |
Dansoft Denmark (10-05-2001)
| Kommentar Fra : Dansoft Denmark |
Dato : 10-05-01 21:53 |
|
--
"Torben Wridt" <oz6tw@qsl.net> wrote in message
news:9dde6a$ss4$1@news.net.uni-c.dk...
> Hej!!
> Er ny her i NG, og starter op med et sikkert noget "dumt" spørgsmål, hi.
>
> Har igennem flere år brugt et kit fra fa. Velleman som hedder K-8000. Det
er
> et elektronik-modul som drives via en LPT-port og som indeholder 16
digitale
> kanaler, og et antal analoge AD'ere og ditto DA'ere. "Hemmeligheden" er
så,
> at signalerne fra printerporten "konverteres" til en IIC-bus.
> Til at foretage den egentlige timing etc. af denne bus medleverer Velleman
> bl.a. en unit-fil til Pascal-folk, og en header-fil til C-folk. Har indtil
> dato brugt modulet i.forb. med Pascal-programmer, men fandt det mere
> "fremtidssikkert" at konvertere til C!!
> Og så startede mine problemer....Har ikke før selv skrevet endsige
> implementeret "fremmede" include-filer!
>
> Den medfølgende "I2C.C" har jeg compilet med compilerens(en "gammel"
version
> 3) "library"-funktion. De derved generede I2C.lib og I2C-obj filer har jeg
> smidt ind i compilerens "library"-dir. Den medfølgende header-fil, som
> hedder I2C.h er placeret i "header"-dir. (Matcher naturligvis compilerens
> opsætning mht. dirs)
>
> Med kittet er der en hel del demo-software. Problemet er, at jeg ikke kan
få
> disse eksempler til at funke. Compileren fejl-melder, at den ikke kan
finde
> de funktionskald som er indeholdt i headerfilen.....
>
> Æhhh......, hvad gør JEG forkert????
>
Hej
Har du husket at inkludere din header fil i I2C.C ved at skrive #include
<I2C.h> i starten af din C file?
Hilsen Torben
E-Mail: dansoft-denmark@dansoft-denmark
URL: http://www.dansoft-denmark.dk
| |
Torben Wridt (14-05-2001)
| Kommentar Fra : Torben Wridt |
Dato : 14-05-01 09:58 |
|
Dansoft Denmark <dansoft-denmark@dansoft-denmark.dk> skrev i en
nyhedsmeddelelse:e3DK6.321$qY.11272@news.get2net.dk...
>
>
> --
>
> "Torben Wridt" <oz6tw@qsl.net> wrote in message
> news:9dde6a$ss4$1@news.net.uni-c.dk...
> > Hej!!
> > Er ny her i NG, og starter op med et sikkert noget "dumt" spørgsmål, hi.
> >
> > Har igennem flere år brugt et kit fra fa. Velleman som hedder K-8000.
Det
> er
> > et elektronik-modul som drives via en LPT-port og som indeholder 16
> digitale
> > kanaler, og et antal analoge AD'ere og ditto DA'ere. "Hemmeligheden" er
> så,
> > at signalerne fra printerporten "konverteres" til en IIC-bus.
> > Til at foretage den egentlige timing etc. af denne bus medleverer
Velleman
> > bl.a. en unit-fil til Pascal-folk, og en header-fil til C-folk. Har
indtil
> > dato brugt modulet i.forb. med Pascal-programmer, men fandt det mere
> > "fremtidssikkert" at konvertere til C!!
> > Og så startede mine problemer....Har ikke før selv skrevet endsige
> > implementeret "fremmede" include-filer!
> >
> > Den medfølgende "I2C.C" har jeg compilet med compilerens(en "gammel"
> version
> > 3) "library"-funktion. De derved generede I2C.lib og I2C-obj filer har
jeg
> > smidt ind i compilerens "library"-dir. Den medfølgende header-fil, som
> > hedder I2C.h er placeret i "header"-dir. (Matcher naturligvis
compilerens
> > opsætning mht. dirs)
> >
> > Med kittet er der en hel del demo-software. Problemet er, at jeg ikke
kan
> få
> > disse eksempler til at funke. Compileren fejl-melder, at den ikke kan
> finde
> > de funktionskald som er indeholdt i headerfilen.....
> >
> > Æhhh......, hvad gør JEG forkert????
> >
> Hej
> Har du husket at inkludere din header fil i I2C.C ved at skrive #include
> <I2C.h> i starten af din C file?
>
> Hilsen Torben
>
> E-Mail: dansoft-denmark@dansoft-denmark
>
> URL: http://www.dansoft-denmark.dk
>
Mange tak for dit hurtige svar!
Jeps, jeg har included I2C-headerfilen i I2C.c inden denne blev compilet.
Se evt. mit indlæg til en anden der har svaret!
Mange tak!
Mvh Torben.
| |
Richard Flamsholt (11-05-2001)
| Kommentar Fra : Richard Flamsholt |
Dato : 11-05-01 00:23 |
|
"Torben Wridt" <oz6tw@qsl.net> skrev:
>Compileren fejl-melder, at den ikke kan finde
>de funktionskald som er indeholdt i headerfilen.....
Der kan være utallige årsager, så derfor:
Hvad fejl-melder compileren helt præcis?
--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk
| |
Torben Wridt (14-05-2001)
| Kommentar Fra : Torben Wridt |
Dato : 14-05-01 10:04 |
|
Richard Flamsholt <richard@flamsholt.dk> skrev i en
nyhedsmeddelelse:bi8mftsf8o5fs2asiv1t6o4v9lglb8t0kv@sunsite.auc.dk...
> "Torben Wridt" <oz6tw@qsl.net> skrev:
> >Compileren fejl-melder, at den ikke kan finde
> >de funktionskald som er indeholdt i headerfilen.....
>
> Der kan være utallige årsager, så derfor:
> Hvad fejl-melder compileren helt præcis?
>
> --
> Richard Flamsholt
> richard@flamsholt.dk - www.richard.flamsholt.dk
Hej, og tak for din ulejlighed med at svare!
Et eksempel:
Et funktionskald fra header-filen kunne være "SelectI2CprinterPort"
Når jeg forsøger at compile fås følgende fejl-melding:
"*linker error: Undefined symbol _SelectI2CprinterPort in module ........"
(Bemærk den tilførte underscore)
Jeg benytter en Turbo C++ version 3, gammel, men normal OK.
Øh....., leder det dig ind på noget spor?
Mvh, en snart noget gråhåret, ))
| |
Mogens Hansen (14-05-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 14-05-01 19:47 |
|
Hej Torben,
"Torben Wridt" <oz6tw@qsl.net> wrote in message
news:9do74s$eu4$1@news.net.uni-c.dk...
> Et eksempel:
> Et funktionskald fra header-filen kunne være "SelectI2CprinterPort"
> Når jeg forsøger at compile fås følgende fejl-melding:
> "*linker error: Undefined symbol _SelectI2CprinterPort in module ........"
> (Bemærk den tilførte underscore)
> Jeg benytter en Turbo C++ version 3, gammel, men normal OK.
Det er DOS ?
>
> Øh....., leder det dig ind på noget spor?
Du skal bruge 2 ting:
1. En headerfil - den har du allerede
2. En implementering - C-fil, OBJ-fil eller LIB-fil.
Compileren (linkeren) har svært ved at finde implementeringen.
Du har, at dømme efter dit oprindelige inlæg, en "i2c.c" fil, som indeholder
implementeringen.
Det at du lægger OBJ-filen eller LIB-filen i compilerens library bibliotek
gør _ikke_ at compileren kan finde dem.
Du skal includere dem i dit projekt. Det nemmeste er formodentlig at
includere source-filen "i2c.c" filen i dit projekt, så burde der være en
chance for at compileren og linkeren klare resten.
Inkluderer du headerfilen i en C eller en C++ fil ? (Det _kan_ spille en
rolle for hvilket navn linkeren leder efter - afhængigt af hvordan
headerfilen er lavet)
Venlig hilsen
Mogens Hansen
| |
Torben Wridt (15-05-2001)
| Kommentar Fra : Torben Wridt |
Dato : 15-05-01 08:47 |
|
Mogens Hansen <mogens_h@dk-online.dk> skrev i en
nyhedsmeddelelse:9dpali$2ur$1@news.cybercity.dk...
> Hej Torben,
> "Torben Wridt" <oz6tw@qsl.net> wrote in message
> news:9do74s$eu4$1@news.net.uni-c.dk...
> > Et eksempel:
> > Et funktionskald fra header-filen kunne være "SelectI2CprinterPort"
> > Når jeg forsøger at compile fås følgende fejl-melding:
> > "*linker error: Undefined symbol _SelectI2CprinterPort in module
........."
> > (Bemærk den tilførte underscore)
> > Jeg benytter en Turbo C++ version 3, gammel, men normal OK.
>
> Det er DOS ?
>
> >
> > Øh....., leder det dig ind på noget spor?
>
> Du skal bruge 2 ting:
> 1. En headerfil - den har du allerede
> 2. En implementering - C-fil, OBJ-fil eller LIB-fil.
>
Jeps! som du har bemærket er implementeringen i en i2c.c-fil.
> Compileren (linkeren) har svært ved at finde implementeringen.
>
> Du har, at dømme efter dit oprindelige inlæg, en "i2c.c" fil, som
indeholder
> implementeringen.
> Det at du lægger OBJ-filen eller LIB-filen i compilerens library bibliotek
> gør _ikke_ at compileren kan finde dem.
> Du skal includere dem i dit projekt. Det nemmeste er formodentlig at
> includere source-filen "i2c.c" filen i dit projekt, så burde der være en
> chance for at compileren og linkeren klare resten.
>
Klart nok!! Hvis jeg includer i2c.c filen i mit projekt er der ingen
problemer(det burde jeg vel have omtalt, hm).
Men det betyder vel også, at min compilede exe-fil bliver større end
nødvendigt?!
(i2c.h-filen indeholder egentlig kun definitions og prototyping).
> Inkluderer du headerfilen i en C eller en C++ fil ? (Det _kan_ spille en
> rolle for hvilket navn linkeren leder efter - afhængigt af hvordan
> headerfilen er lavet)
>
Det foregår altsammen i C.
> Venlig hilsen
>
> Mogens Hansen
>
Kære Mogens Hansen!!
Du skal have tak for dit konstruktive indlæg. Det blev jeg meget glad for.
Som du nok aner, er jeg ikke særlig gammel
hvad angår C-sproget. Har benyttet Pascal indtil for ca. 1 år siden, hi.
Mangen venlige hilsner!
Torben W.
| |
Mogens Hansen (15-05-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 15-05-01 10:27 |
|
Hej Torben
"Torben Wridt" <oz6tw@qsl.net> wrote in message
news:9dqn0f$re4$1@news.net.uni-c.dk...
> >
> Klart nok!! Hvis jeg includer i2c.c filen i mit projekt er der ingen
> problemer(det burde jeg vel have omtalt, hm).
> Men det betyder vel også, at min compilede exe-fil bliver større end
> nødvendigt?!
Den bliver større - men ikke større end _nødvendigt_ (altså under
forudsætning af at du har brug for funktionaliteten i "i2c.c" - og det har
du efter alt at dømme).
Og ikke større end hvis du bruger LIB- eller OBJ-filer - det er det samme.
Venlig hilsen
Mogens Hansen
| |
Torben Wridt (15-05-2001)
| Kommentar Fra : Torben Wridt |
Dato : 15-05-01 10:34 |
|
Mogens Hansen <mogens_h@dk-online.dk> skrev i en
nyhedsmeddelelse:3b00f652$1@lxcs1.manbw.dk...
> Hej Torben
> "Torben Wridt" <oz6tw@qsl.net> wrote in message
> news:9dqn0f$re4$1@news.net.uni-c.dk...
> > >
> > Klart nok!! Hvis jeg includer i2c.c filen i mit projekt er der ingen
> > problemer(det burde jeg vel have omtalt, hm).
> > Men det betyder vel også, at min compilede exe-fil bliver større end
> > nødvendigt?!
>
> Den bliver større - men ikke større end _nødvendigt_ (altså under
> forudsætning af at du har brug for funktionaliteten i "i2c.c" - og det har
> du efter alt at dømme).
> Og ikke større end hvis du bruger LIB- eller OBJ-filer - det er det samme.
>
> Venlig hilsen
>
> Mogens Hansen
>
OK!! Mange tak for dine klare ord!!! Herligt når nettet bliver brugt på
denne måde!
Mange venlige hilsner, Torben Wridt, Middelfart.
| |
Byrial Jensen (19-05-2001)
| Kommentar Fra : Byrial Jensen |
Dato : 19-05-01 08:53 |
|
Mogens Hansen <mogens_h@dk-online.dk> skrev:
>Den bliver større - men ikke større end _nødvendigt_ (altså under
>forudsætning af at du har brug for funktionaliteten i "i2c.c" - og det har
>du efter alt at dømme).
>Og ikke større end hvis du bruger LIB- eller OBJ-filer - det er det samme.
Den bliver måske større end hvis han bruger LIB-filer, hvis han ikke
bruger alle funktionerne i i2c.c, og hvis den linker han bruger, kan
nøjes med at medlinke de funktioner som rent faktisk bruges fra en
LIB-fil.
| |
Mogens Hansen (19-05-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 19-05-01 17:18 |
|
Hej Byrial,
"Byrial Jensen" <bjensen@nospam.dk> wrote in message
news:slrn9gc92u.kv.bjensen@ask.ask...
> Mogens Hansen <mogens_h@dk-online.dk> skrev:
> >Den bliver større - men ikke større end _nødvendigt_ (altså under
> >forudsætning af at du har brug for funktionaliteten i "i2c.c" - og det
har
> >du efter alt at dømme).
> >Og ikke større end hvis du bruger LIB- eller OBJ-filer - det er det
samme.
>
> Den bliver måske større end hvis han bruger LIB-filer, hvis han ikke
> bruger alle funktionerne i i2c.c, og hvis den linker han bruger, kan
> nøjes med at medlinke de funktioner som rent faktisk bruges fra en
> LIB-fil.
Det er _ikke_ nødvendigvis rigtigt hvad du siger.
Der er en lille grund til at sige tværtimod - ikke mindst på den i denne
tråd omtalte platform (MS-DOS og Turbo C++ V3.0).
Hvor meget og hvor lidt der kommer med fra en LIB-fil er platforms
afhængigt - det er ikke defineret i sprogstandarden.
Der er _ikke_ noget krav om at alle funktioner i en source-fil linkes med,
hvis de ikke bliver refereret.
Se f.eks. compiler option /Gy (Enable Function-Level Linking) i Micrsoft
Visual C++ (fra V5 og fremefter, så vidt jeg husker).
Selv ikke-kaldte virtuelle funktioner behøves ikke at blive linket med,
selvom de egentlig bliver refereret fra den virtuelle funktionstabel (på en
typisk implementation). Få compilere/linkere har dog implementeret denne
optimering (Sybase Watcom C++ 10.0 gjorde, og det er så vidt jeg er
orienteret ved gcc at implementere det).
De typiske "simple" LIB implementering som jeg har set, virker på den måde
at hvis een funktion i en compilation unit bliver _alle_ funktionerne i den
compilation unit medtaget. For at opnå den effekt som du snakker om, gør
run-time library implementeringerne typisk det at de laver een compilation
unit pr. funktion (f.eks. een for "strcpy", een for "strcmp" etc.).
Det er således ikke en egenskab ved compiler/linker, men partitioneringen af
library implementationen.
Det som jeg har set, er at linkeren tager et givent kode-segment med, hvis
een funktion er refereret i den. Compileren kan så vælge at lægge hver
funktion i en given compilation unit i separate kode-segmenter (f.eks.
"Enable Function-Level Linking" optionen). Herved bliver linkeren i stand
til at kun linke netop de funktioner, der faktiske bliver refereret, med.
Dette er uafhængigt af om linkeren linker en LIB-fil eller en OBJ-fil med.
Med hensyn til den i denne tråd omtalte platform - MS-DOS - vil compilerene
typisk lægge _alle_ funktioner i en given compilation unit i samme
kode-segment, fordi det giver mulighed for at lave "near call" i stedet for
"far call", hvilket performancemæssigt er at foretrække.
Jeg er derfor rimelig sikker på at det er rigtigt når jeg sagde "Og ikke
større end hvis du bruger LIB- eller OBJ-filer - det er det samme".
Jeg har _ikke_ installeret min gode gamle Borland C++ V3.1 (som er det
nærmeste jeg har) for at verificere det.
Har du _konkret_ _viden_ om at det er forkert - eller er det en mulighed som
du kan _forestille_ dig ?
Det betyder _ikke_ at anvendelsen af LIB-filer og source-filer (og
OBJ-filer) er _fuldstændig_ ækvivalent.
Jeg har f.eks. set at hvis en source-fil indeholder et global objekt, som
ikke bliver refereret (ved navn) fra andre steder, vil det objekt blive
linket med, hvis man angiver OBJ-filen til linkeren, men objektet vil _ikke_
blive linket med, hvis det ligger i en LIB-fil.
Venlig hilsen
Mogens Hansen
| |
Byrial Jensen (20-05-2001)
| Kommentar Fra : Byrial Jensen |
Dato : 20-05-01 07:44 |
|
Mogens Hansen <mogens_h@dk-online.dk> skrev:
>Hej Byrial,
>"Byrial Jensen" <bjensen@nospam.dk> wrote in message
>>
>> Den bliver måske større end hvis han bruger LIB-filer, hvis han ikke
>> bruger alle funktionerne i i2c.c, og hvis den linker han bruger, kan
>> nøjes med at medlinke de funktioner som rent faktisk bruges fra en
>> LIB-fil.
>
>Det er _ikke_ nødvendigvis rigtigt hvad du siger.
>[...]
>Har du _konkret_ _viden_ om at det er forkert - eller er det en mulighed som
>du kan _forestille_ dig ?
Hej Mogens,
Jeg er helt enig i alle de betragtninger som jeg har klippet væk
ovenfor. Prøv at læse mit første indlæg igen: Jeg skrev netop at
det er en /mulighed/ at en linker kan nøjes med at udvælge enkelte
funktioner fra bibliotek. Jeg har ingen viden om hvordan den
oprindelige spørgers programmeringværtøjer er lavet med hensyn til
dette.
| |
Mogens Hansen (20-05-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 20-05-01 08:53 |
|
Hej Byrial,
"Byrial Jensen" <bjensen@nospam.dk> wrote in message
news:slrn9gepl1.lk.bjensen@ask.ask...
> Mogens Hansen <mogens_h@dk-online.dk> skrev:
> >Hej Byrial,
> >"Byrial Jensen" <bjensen@nospam.dk> wrote in message
> >>
> >> Den bliver måske større end hvis han bruger LIB-filer, hvis han ikke
> >> bruger alle funktionerne i i2c.c, og hvis den linker han bruger, kan
> >> nøjes med at medlinke de funktioner som rent faktisk bruges fra en
> >> LIB-fil.
> >
> >Det er _ikke_ nødvendigvis rigtigt hvad du siger.
> >[...]
> >Har du _konkret_ _viden_ om at det er forkert - eller er det en mulighed
som
> >du kan _forestille_ dig ?
>
> Hej Mogens,
>
> Jeg er helt enig i alle de betragtninger som jeg har klippet væk
> ovenfor. Prøv at læse mit første indlæg igen: Jeg skrev netop at
> det er en /mulighed/ at en linker kan nøjes med at udvælge enkelte
> funktioner fra bibliotek. Jeg har ingen viden om hvordan den
Jeg læste (og læser fortsat) dit indlæg således at der er et performance
argument (program størrelse) for at bruge LIB-filer i stedet for
source-filen direkte, hvilket jeg ikke mener særligt ofte (afhængig af
platform) er tilfældet.
Venlig hilsen
Mogens Hansen
| |
|
|