From: Josh G. <jo...@li...> - 2003-06-22 00:10:20
|
On Sun, 2003-06-22 at 01:27, Tor Lillqvist wrote: > Josh Green writes: > > When linking the DLL plugin it fails due to undefined symbols, all > > of which are in the main program that will be dlopening it. > > You will have to know those functions in advance, and mark them (in > the main program's source) with __declspec(dllexport). Only then will > they be exported from the .exe file. (In the same way as entry points > are exported from DLLs; the difference between a DLL and EXE is > minimal.) > I was afraid of that possibility, I can for see a bit of time spent marking my header files in the near future. > Then, unless you know that the plugin DLL will always be used from a > main program with the same name, you will have to look up the function > address at run time in the DLL using g_module_symbol(), passing in a > GModule* you get from calling g_module_open with a NULL file_name > argument. > > (Otherwise, if you know that the only user of the DLL will be called > foobar.exe, you can build an import library for foobar.exe, and link > your DLL with that as if it was an import library for some normal > DLL.) > The plugins will always be loaded from the same program, and it won't change. So I think I will try going the second route. I'm not familiar with import libraries though, but now that I know the term I can probably locate some info on it. > --tml > Thanks for the quick response. I'd like to also thank you for your work on porting GTK and support libs to Win32, without this there would be no hope for porting my program to this platform. I'm amazed at how painful windows is concerning shared libraries and the like. Its almost more work than its worth (its worth being the size of the user base only, really, IMNSHO). Cheers. Josh Green |