[C++] link problemen: unresolved external symbol problemen

[Verwijderd]

Ik ben bezig met een DLL die wat calls naar de windows API (shell) moet uitvoeren, maar nu krijg ik voor elke windows functie die ik aanroep een fout van de linker:

code:

   Creating library Toolkit.lib and object Toolkit.exp
Toolkit.obj : error LNK2019: unresolved external symbol __imp__FindWindowA@8 referenced in function _Java_nl_netforge_win_Toolkit_getHwnd@12

Om deze foutmelding te krijgen heb ik het volgende ingetypt:

code:

cl /I"C:\Program Files\Microsoft SDK\include" /Ic:\j2sdk1.4.0\include /Ic:\j2sdk1.4.0\include\Win32 *.cpp /LD /link /LIBPATH:"C:\Program Files\Microsoft SDK\Lib"

Ik compileer in een dos box onder XP prof met cl.exe die bij het .net framework zat. De DLL die ik probeer te maken heb ik eerder al eens aangemaakt met Visual studio 6, maar daar heb ik de CD niet meer van. Weet iemand misschien wat ik hier fout doe, want met visual studio had ik dit probleem eerst ook, alleen weet ik niet meer hoe ik dat toen heb opgelost.

Is het eigenlijk wel mogelijk om DLL's met window calls te compileren met alleen het .net framework (eenvoudige DLL's zijn geen probleem, volgens een voorbeeldje bij de samples tenminste)?

Alvast bedankt.

[farlane]

Je zult of met een compiler switch de obj statisch moeten linken of de DLL dynamisch laden ( in Win32 met LoadLibrary( ... ) ).

Hoe dit in .net gaat weet ik eigenlijk niet.

[Verwijderd]

Ik heb het probleem _hoop ik_ gevonden. Om C++ te linken zonder gebruik te maken van het .net framework moet je schijnbaar toch nog de MS core platform SDK geinstalleerd hebben. Dynamisch linken (in ieder geval zonder de DLL zelf in te laden) zou dan toch gewoon mogelijk moeten zijn, want via visual studio werkte dat ook gewoon.

Bij de .net docs staat (lees: vind ik) nergens hoe en of je de API via C++ kunt gebruiken, maar als ik tegelijk #using statements en #include statements in m'n code bebruik krijg ik wel een aantal meldingen over ambigous symbols... Betekent dit dat je op de een of andere manier zonder #include Windows.h, maar met #using Miscrosoft.Win32 (of zoiets) gewoon de C functies kunt gebruiken

Over een uur of 7 (k*t ISDN ) zal ik wel zien of het met de platform SDK wel werkt...

[Verwijderd]

*zucht*

Laat maar, ik was vergeten om expliciet alle libraries op te geven die de linker moest gebruiken Voor degene die het interesseert, zo moet het:

code:

cl  /Ic:\j2sdk1.4.0\include /I"C:\Program Files\Microsoft SDK\include" *.cpp /LD
 /link shell32.lib user32.lib Gdi32.lib /LIBPATH:"C:\Program Files\Microsoft SDK
\Lib\"

[.oisyn]

farlane schreef op 26 augustus 2002 @ 22:20:
Je zult of met een compiler switch de obj statisch moeten linken of de DLL dynamisch laden ( in Win32 met LoadLibrary( ... ) ).

met LoadLibrary () los je geen unresolved external symbol errors op, aangezien de linker at linktime naar de symbols zoekt

[MSalters]

.oisyn schreef op 27 augustus 2002 @ 00:00:

met LoadLibrary () los je geen unresolved external symbol errors op, aangezien de linker at linktime naar de symbols zoekt

Om nog even aan het probleem voorbij te gaan dat LoadLibrary ook een library functie is, dus als je helemaal geen libraries linkt dan kun je LoadLibrary ook niet gebruiken.

[farlane]

.oisyn schreef op 27 augustus 2002 @ 00:00:

[...]


met LoadLibrary () los je geen unresolved external symbol errors op, aangezien de linker at linktime naar de symbols zoekt

Je kunt functies uit een dll op drie verschillende manieren gebruiken:
Je linkt een obj (statisch linken)
Je linkt een lib (runtime statisch linken)
Je gebruikt LoadLibrary & GetProcAddress en aanverwanten (runtime dynamic linken)

In het derde geval zoekt de compiler(linker) tijdens linken niet naar de symbols, maar maak je gebruik van functiepointers.

Zie ook : http://msdn.microsoft.com..._core_link_explicitly.asp

Call GetProcAddress to obtain a function pointer to each exported function that the application wants to call. Because applications are calling the DLL’s functions through a pointer, the compiler does not generate external references, so there is no need to link with an import library.

Dat LoadLibrary een functie uit een dll is is me bekend. Ik zou echter verwachten dat .Net daar een equivalent voor heeft. ( Zoals ik al zei ben ik niet bekent met de details van et .Net verhaal )

[.oisyn]

farlane schreef op 28 augustus 2002 @ 01:11:
[...]


Je kunt functies uit een dll op drie verschillende manieren gebruiken:
Je linkt een obj (statisch linken)
Je linkt een lib (runtime statisch linken)
Je gebruikt LoadLibrary & GetProcAddress en aanverwanten (runtime dynamic linken)

juist, en aangezien hij linker errors kreeg heeft simpelweg gebruik van LoadLibrary () weinig nut, omdat hij in z'n headers referenties heeft staan naar vaste functies (en dus niet pointers naar functies)

Overigens, linken met .obj en .lib is allebei statisch linken, tenzij de .lib naar een .dll refereert, dan heet het load-time dynamisch linken

[curry684]

farlane schreef op 28 augustus 2002 @ 01:11:
Je kunt functies uit een dll op drie verschillende manieren gebruiken:
Je linkt een obj (statisch linken)
Je linkt een lib (runtime statisch linken)
Je gebruikt LoadLibrary & GetProcAddress en aanverwanten (runtime dynamic linken)
In het derde geval zoekt de compiler(linker) tijdens linken niet naar de symbols, maar maak je gebruik van functiepointers.

Sowieso dien je dan dus nog immer Kernel32.lib op de commandline mee te geven, maar ik moet zeggen dat je wel een uitgesproken bikkel bent als je op die manier gaat coden in de trant van:

code:

typedef HWND (*t_FindWindowA)(LPCTSTR, LPCTSTR) ;

HMODULE          l_UserLib = LoadModule("User32.lib");
t_FindWindowA    l_FindWindowA = GetProcAddress(l_UserLib, "FindWindowA");
HWND             l_Window;

l_Window = l_FindWindowA(NULL, "Windows Task Manager");

Dan kun je net zo goed meteen assembler pakken

[farlane]

Wordt idd wat meer werk

Naja, het was ook meer bedoeld om aan te geven dat als je LoadLibrary en functiepointers gebruikt, je niet tijdens compileren een unresolved external krijgt. ( In de situatie die websjwans schetst is het niet echt op zijn plaats.)