[C++] unresolved link error

[dirkpostma]

Ik beschik over een VC5 project. Deze compileert & linked prima. Nu wil ik overgaan naar VC6, maar hierbij gaat het fout bij het linken van een externe library (waarvan ik de source niet heb).

Ik heb hier laatst ook een vraag over gesteld, maar toen dacht ik dat de libraries niet compatible waren. Dit is volgens mij niet het geval. Het heeft volgens mij meer iets te maken met declaraties in headerfiles ofzo, aangezien ik een van de unresolved link errors heb weten weg te werken door het volgende (gebruik makend van een .MAP file):

code:

int __cdecl RandomNumber(void);
//__int32 RandomNumber();

Nu wilde ik hetzelfde proberen met de overige unresolved link errors, bv:

code:

Linking...
poosldata.lib(ppdm_keyboard.obj) : error LNK2001: unresolved external symbol "public: void __thiscall POOSLScheduler::AddExternalEventHandler(__int32 (__cdecl*)(void))" (?AddExternalEventHandler@POOSLScheduler@@QAEXP6A_HXZ@Z)

maar als ik in de source code hetvolgende verander:

code:

//void AddExternalEventHandler(ExternalEventHandler EEH);
void __thiscall AddExternalEventHandler(__int32 (__cdecl*)(void));

krijg ik de error dat __thiscall een keyword is reserved voor de future:

code:

ppdm_ir_transceiver.cpp
G:\Rotalumis\vc6_01\executionengine\data\primitivedata\../../system/scheduler.h(73) : error C4234: nonstandard extension used : '__thiscall' keyword reserved for future use
G:\Rotalumis\vc6_01\executionengine\data\primitivedata\ppdm_ir_transceiver.cpp(35) : error C2664: 'AddExternalEventHandler' : cannot convert parameter 1 from '__int32 (__cdecl *)(void)' to 'int (__cdecl *)(void)'
      This conversion requires a reinterpret_cast, a C-style cast or function-style cast

Wie helpt? Ik zit er al weken mee ... Alvast bedankt!

[Verwijderd]

Kan je niet een zip file ergens neer rotten met een klein test projectje zodat we even mee kunnen kijken?

[dirkpostma]

Zou je me misschien even je emailadres bekend willen maken, dan kan ik die zip naar je mailen (ik maak het liever niet heel erg openbaar). Je kunt mailen naar [e-mail]. Alvast bedankt!

[farlane]

Wil je klassen in die dll gaan aanspreken? Kweetniet of dat wel zo goed gaat als je een andere compiler gebruikt dan de maker van de dll.

[dirkpostma]

Het is geen DLL, maar een meegelinkte .lib. Maar inderdaad, het geeft wat problemen. Ik zie in de MSDN documentatie echter geen issues wat betreft het "porten" van VC5 naar VC6.

[Verwijderd]

Vergeet je niet gewoon een lib mee te linken?

[dirkpostma]

nee; bovendien: ik heb een VC5 project, daar werkt het. Dit VC5 project open ik in VC6 (waarbij VC6 enige zaken converteert), en daar werkt het niet. Ik heb je per mail inmiddels een .zip verstuurd met het VC5 project.

[dirkpostma]

Ik heb van iemand per email een antwoord gekregen:

Volgens mij wordt het probleem veroorzaakt door het feit dat naam van de de member functie is 'ge-namemangled' tijdens het bouwen van de library. Dit houdt in dat de linker de namen van gexporteerd symbolen aanpast volgens een
vendor specifiek algoritme. Hierdoor is het vaak zeer lastig om C++ code in libraries te zetten en deze te gebruiken met verschillende compilers, c.q. versies.

Om dit werkend te krijgen zul je de broncode van de library aan moeten passen zodat de functie met extern C wordt geexporteerd. Of je zult genoegen moeten nemen door dezelfde compiler/linker te gebruiken die voor de library is gebruikt.

Hij heeft het over een "vendor" specifiek algoritme. In dit geval heeft is Microsfot in beide gevallen de vendor. Zou het op zich zo moeten zijn dat de VC6 compiler het wel zou moeten slikken, maar dat er wellicht een bugje in zit?

Verder: is het uberhaupt mogelijk om functies die niet voorzien zijn van "extern C" aan te roepen? (misschien een tikkeltje newbie-vraag, maar dat ben ik eigenlijk ook aangezien ik nog nooit echt link-problemen heb gehad, vandaar)

[Verwijderd]

Ik heb 'm nog niet aan de gang onder vc6, vc7 compiled en linkt zonder problemen gek genoeg..

[farlane]

Het is niet zeker dat het formaat van de objectbestanden bij beide compilers hetzelfde is.

Vind het wel vreemd dat het in dit geval ook niet kan, daar beide compilers van MS zijn.

[Verwijderd]

Zeer vreemd zeker gezien vc7 het wel gewoon doet..

hij kakt de volgende defs uit voor die functie

code:

vc6:AddExternalEventHandler@POOSLScheduler@@QAEXP6A_HXZ@Z
vc7:AddExternalEventHandler@POOSLScheduler@@QAEXP6AHXZ@Z

die underscore nekt 'm dus.. ik denk ik edit gewoon die stringtable in die object file even is voor die random call wel gelukt (zeer kleine obj zonder veel gedoe er in), die Scheduler lukt echter nie, als ik de stringtable van die obj edit maak ik 'm corrupt!? jij ervaring met editen van obj files farlane?

[farlane]

Moet zeggen dat ik me daar nooit echt mee bezig heb gehouden

Het kan zijn dat er ergens een lengte in je obj bewaard wordt, om dit soort dingen te vermijden. Eens ff kijken of ik wat kan vinden over dit fenomeen...

[farlane]

Overigens, als je functies wilt importeren in je exe, is het weliswaar belangrijk hoe de dll is gecompileerd, maar het is belangrijker dat de header die je krijgt overeenstemt met de lib.

dwz, als de dll c style functies gebruikt, en je importeert in een c++ progje, moet er in je header extern "C" voor de functies staan, om de linker te vertellen naar welke functienamen hij moet zoeken in de .lib.

Dat is bij jouw niet het geval, want volgens mij slaat dat __thiscall erop dat het hier om een memberfunctie gaat, en zoals we allemaal weten kent c die niet.

[edit]
in KB artikel Q138400 staat ook nog het een en ander uitgelegd over linken en namedecoration ed.

[Verwijderd]

Er zijn geen dll's, de lib wordt gewoon static mee gelinkt en verder geen speciale fratsen, de header files zijn ook in oorde (het compileerd immers gewoon onder vc5/7) , lengte van je stringtable wordt inderdaad bij gehouden maar die had ik aangepast , heb het idee dat doordat alles 1 byte opschuift iets van een realloc table gaar raakt ergens ofzo..

[curry684]

Op donderdag 13 september 2001 17:19 schreef Yarvieh het volgende:
Ik heb 'm nog niet aan de gang onder vc6, vc7 compiled en linkt zonder problemen gek genoeg..

VC6 base version is zwaar bugged, heb je de laatste service pack (4 geloof ik) er al overheen gegooid?

VC6 code zonder service packs knalt onder andere op kernellevel als je vanuit een exceptionhandler een andere exception gooit (heel humor, instant exit).

edit:

Niet knallend fout voorbeeld verwijderd

Main idea: VC6 is een hopeloze stapel bugs.

[farlane]

Hier:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_results_of_calling_example.asp

staat ook nog wat uitgelegd over calling conventions. Er staat oa ook dat de C++ namedecoration proprietary is, wat dus inhoud dat je dat zelf mag bedenken. (Waar MS dus kennelijk ook dankbaar gebruik van heeft gemaakt)

('scuses voor de belachelijk lange url.)

...
Er zijn geen dll's, de lib wordt gewoon static mee gelinkt en verder geen speciale fratsen
...

Was het niet zo dat je naast je lib ook nog een dll nodig had, of is dit weer een andere linken dan de 'loadtime static linking' waar ik het over heb?

( 'loadtime static' .....rare jongens die MS'ers )

[edit]

oepsiedaisie....

[Verwijderd]

Er vanuit gaande dat je bewust die typo hebt gemaakt (zonder typo ook geen error namelijk)

Vc6 poept uit:

error C2143: syntax error : missing ';' before ':'
warning C4508: 'Dummy' : function should return a value; 'void' return type assumed

vc7:

error C2143: syntax error : missing ';' before ':'
error C2059: syntax error : ':'
warning C4508: 'Dummy' : function should return a value; 'void' return type assumed

[dirkpostma]

Ten eerste: allemaal heel erg bedankt voor de reacties! Ik ben momenteel VS6 Service Pack 5 (133 MB!) aan het downloaden. Hopelijk lukt het dan wel. To be continued...

[curry684]

Op donderdag 13 september 2001 22:31 schreef Yarvieh het volgende:
Er vanuit gaande dat je bewust die typo hebt gemaakt (zonder typo ook geen error namelijk)

Hmmm ben even wat aan het checken, maar toen ik vandeweek die typo maakte kreeg ik Internal Compiler Error, en toen ik 'm ergens anders express veroorzaakte net zo hard. Hoorde ik van een collega dat die 'm ook al eens had gezien...

Doet het kutding het blijkbaar niet in zo'n klein programmaatje

[edit]
Nope krijg 'm in een one-file exe project niet aan het knallen (had het vandeweek op m'n werk in een 200 file lib, maar die heb ik hier thuis niet zomaar liggen )

[dirkpostma]

Heb zojuist Service Pack 5 geinstalleerd, maar helaas... dezelfde errors