Combineren van C en C++, LoadLibrary troubles

[Arjan]

Ik loop tegen een probleem aan waarbij ik niet kan verklaren wat er nu misgaat.

We hebben enkele filters geschreven in C, en deze hebben elk een eigen GUI, geschreven in C++/wxWidgets.

Het wxWidgets gedeelte is samengevat in één classe, die vanuit een wxWidgets gebaseerde toepassing aan te roepen is.
Echter, omdat de filters in C geschreven zijn, en deze op een of andere manier de GUI's met zich mee moeten dragen, had ik het volgende bedacht:

applicatie -> laad het filter (C - dll) -> bevat een call die de juiste GUI oproept

Echter, zodra deze laatste call in de C -dll gezet wordt, lijkt er iets mis te gaan met exporteren. Hoewel objdump nog steeds dezelfde functies kent, kan LoadLibrary de functies ineens niet meer laden...

Ik heb geen flauw idee waar ik dit moet zoeken, dus ik hoop dat jullie me opweg kunnen helpen!

alvast bedankt

[Creepy]

Hoe roept je C dll de GUI aan? En wat kan LoadLibrary niet meer laden? Ik neem aan dat dat de DLL geschreven in C moet zijn.
Je hebt wel de juiste calling conventions gebruikt en geen last van C++ name mangling?

[Arjan]

Creepy schreef op maandag 27 augustus 2007 @ 16:13:
Hoe roept je C dll de GUI aan?

in de (c++/wxWidgets) library is de volgende call geimplementeerd:

C++:

extern "C" int openDialog(float* set);

En wat kan LoadLibrary niet meer laden?

C++:

dll = LoadLibrary( TEXT("path van de dll") );

dll blijft NULL, terwijl deze wel geladen wordt als ik bovenstaande call uit de C library laat...

Ik neem aan dat dat de DLL geschreven in C moet zijn.
Je hebt wel de juiste calling conventions gebruikt en geen last van C++ name mangling?

Ik heb overal de extern "C" defenities gebruikt, objdump lijkt het met me eens te zijn:

objdump -x de.dll | grep -i openDialog
        6234      185  openDialog
[384](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000aa0 _openDialog
[476](sec  6)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000158 __imp__openDialog

[igmar]

En welk OS praten we hier over ? Er zijn een aantal systemen die functiecalls prefixen met een _, en aan het bovenstaande te zien is dit er een van.

Verder : Weet je zeker dat alle dependancies geresolved worden ? Libs die niet willen laden kunnen mogelijk de dependancies niet vinden.

[ Voor 32% gewijzigd door igmar op 27-08-2007 16:36 ]

[Arjan]

het gaat hier over Windows XP in combi met MinGW.

Maar het bleek inderdaad aan de dependancies te liggen!
Ik wist niet dat dit verder zonder melding zou gaan, ik verwachtte net als bij een programma de melding dat een .dll niet gevonden kon worden

thanks!

[.oisyn]

igmar schreef op maandag 27 augustus 2007 @ 16:35:
En welk OS praten we hier over ? Er zijn een aantal systemen die functiecalls prefixen met een _, en aan het bovenstaande te zien is dit er een van.

Waar jij het over hebt is iets anders dan de standaard C mangling om voor alle identifiers een _ te zetten, en dat is wat je hier ziet.

Arjan: Altijd GetLastError() checken als je iets terugkrijgt wat je niet verwacht

[ Voor 10% gewijzigd door .oisyn op 27-08-2007 23:09 . Reden: oeps, dank je MSalters :) ]

[MSalters]

"mangling" werkt beter in google.

En natuurlijk kan LoadLibrary niet met een window komen, als er iets fout gaat. Dat zou ten eerste een window probleem zijn (wie is de parent, je geeft geen HWND mee) en ten tweede is het soms de verwachting dat iets fout gaat (plugin systemen), dus de caller is evrantwoordelijk voor de error UI.

[igmar]

.oisyn schreef op maandag 27 augustus 2007 @ 17:14:
Waar jij het over hebt is iets anders dan de standaard C mangling om voor alle identifiers een _ te zetten, en dat is wat je hier ziet.

Het is alleen relevant voor een dlsym() inderdaad, maar die mangling is niet altijd met een _. Op dit verhaal alleen niet van toepassing.

Arjan: Altijd GetLastError() checken als je iets terugkrijgt wat je niet verwacht

Of dlerror() als je een UNIX achtig iets hebt.

[.oisyn]

Laten we *nix even buiten beschouwing laten in dit Windows topic

[Arjan]

.oisyn schreef op dinsdag 28 augustus 2007 @ 11:43:
Laten we *nix even buiten beschouwing laten in dit Windows topic

De software is cross platform, dus in dit geval kwam het wel goed uit