[C++] Unresolved External Symbol

[Tim]

Ik heb een klein progje geschreven (om te oefenen) maar als ik compile dan geeft de linker de foutmelding:

LIBCD.lib(wincrt0.obj) : error LNK2001 : unresolved external symbol _WinMain@16

Weet iemand wat het betekend en hoe ik het moet oplossen?

[farlane]

Ben je un 16 bitter aan het schrijven ? Denk het niet of wel......
Als ik jou was zou ik de settings van de compiler nakijken een de app op 32 bit instellen.

(Werk je met BorlandC ? )

[Tim]

Nee.. Heb gekozen voor een 32bit app..
Werk trouwens met Microsoft Visual C++ 6.0

[JayTaph]

_WinMain@16 wil echt zeggen dat ie een 16bits "main"-functie zoekt. Waarschijnlijk staat er OF een compiler-optie OF een link-optie fout (16 ipv 32 bit).

[Tim]

Krijg ook de foutmelding:
error LNK2001: unresolved external symbol "public: int __thiscall Test::Setvar(int,int)" (?Setvar@Test@@QAEHHH@Z)

Maar als ik de helf (wat obverbodig is) weg comment dan verdwijnt die fout..

Het klopt niet helemaal, want ik kan alleen voor Win32 kiezen en als ik me programma aanpas tot:

#include <iostream.h>

int main() // Start the program
{
cout << "Hallo";
return 0;
}

Dan doet ie het nog steeds niet..
Ik zal nog wat uitproberen, want een 'standaard' Hello World programma doet het prima..

[Tim]

Oke.. Ik had gekozen voor Win32 Application (klonk erg logisch)
Maar ik moest voor Win32 Console Application kiezen..

Sorry.. Deze mag dicht..

[JayTaph]

Heh.. sjah.. Windows Applicaties hebben een WinMain ipv een Main functie (die worden in de crt0.asm opgestart.. Console applicaties zijn de "normale" dos-applicaties (welliswaar 32 bits).

Maar misschien is het toch leuk om een keertje na te gaan waarom dat hij vraagt om _winmain@16 ipv _winmain@32?

[farlane]

Inderdaad, dit is wel wat vreemd. Ik had begrepen dat VC6 helemaal geen 16 bitters meer ondersteunde, maar nu lijkt het alsof de linker een 16bit app wil linken...vreemd.

[Verwijderd]

Ik krijg in C++ builder 3 ongeveer dezelfde melding;

[LinkerError] Unresolved external 'DlPortWritePortUshort' referenced from E:\PRO...NG2.OBJ.

Ben de hele dag al bezig geweest met zoeken naar een oplossing en dingen uitproberen, maar tot nu toe geen oplossing gevonden, en ben nmiddels op het punt gekomen dat ik op het dak ga klimmen om knetterhard te staan schreeuwen

De fout wordt veroorzaakt door deze regel:

DlPortWritePortUshort(BASE_ADDRESS,0);

Het programma wordt een console applicatie in win2k en moet gebruik maken van DLPortIO (gebruikt een headerfile, DLL en library). Tot nu toe dus zonder succes.

[Verwijderd]

je moet die library ook wel mee linken.

[Verwijderd]

Op maandag 10 december 2001 20:33 schreef Yarvieh het volgende:
je moet die library ook wel mee linken.

Library pad klopt wel ("$(BCB)\lib" en "e:\project_lcd\test" bij project => options => directories/conditionals). Dat soort dingen was het eerste waar ik aan dacht, maar maakte geen verschil.

[Verwijderd]

Euh hij gaat echt niet op eigen houdje allerlei library's meelinken omdat ze toevallig in je library path staan hoor, je moet echt ergens aangeven van hee dude deze moet ook..

[Verwijderd]

Op maandag 10 december 2001 20:44 schreef Yarvieh het volgende:
Euh hij gaat echt niet op eigen houdje allerlei library's meelinken omdat ze toevallig in je library path staan hoor, je moet echt ergens aangeven van hee dude deze moet ook..

Bedankt, dat was net de ingeving die ik nodig had

Voeg dit toe bovenaan de source en het werkt;

USELIB("dlportio.lib");

[MSalters]

Op zaterdag 02 september 2000 21:26 schreef JayTaph het volgende:
.<P>Maar misschien is het toch leuk om een keertje na te gaan waarom dat hij vraagt om _winmain@16 ipv _winmain@32?

Uit m'n hoofd: het nummer achter de @ is geen aantal bits,
maar een ordinal in een lib. Dat geeft zeg maar aan dat het
de 16e functie is die gelinkt kan worden. Dan hoef je de
naam niet te weten, en da's weer handig als met C++ name mangling er onmogelijke namen uit komen.

[.oisyn]

eigenlijk is het de totale grootte van de parameters van de functie

en WinMain heeft 4 parameters van elk 4 bytes (32 bits), dus 16 bytes aan parameters

Dit is de C++ name-mangling scheme die VC++ toepast om de verschillende overloadde functies uit elkaar te houden

(heeft dus idd totaal niets met het aantal bits te maken)