From: Luis L. <lui...@gm...> - 2010-10-23 15:39:44
|
Hello, I was attempting to port a program from Linux to Windows where certain functions are exported and used by plugin/extensions. Since the program is not a shared object, there is no import library to link with. Since PE do not allow unresolved symbols to compile, I couldn't find a way to work on this port for Windows without altering the whole application a lot. To make things a bit clearer, this is what I wanted to achieve: test.exe needs to remain the executable but also export some symbols: foo_help and foo_hello Needed to create a import library for these symbols (libtest.a) and allow plugin.dll link to it Every time tried using extern and export these symbols ended with unresolved references to foo_help and foo_hello, even when libtest.a contains those definitions. Also tried with __cdeclspec(dllexport) and __cdeclspec(dllimport) in test and plugin respectively without avail. As I've been suing dynamic languages for quite long, I'm definitely getting rusty at C. Does anyone have a hint to achieve this without radically altering the original program? Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry |
From: JonY <jo...@us...> - 2010-10-23 16:07:54
Attachments:
0xED74C077.asc
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/23/2010 23:39, Luis Lavena wrote: > Hello, > > I was attempting to port a program from Linux to Windows where certain > functions are exported and used by plugin/extensions. Since the > program is not a shared object, there is no import library to link > with. > > Since PE do not allow unresolved symbols to compile, I couldn't find a > way to work on this port for Windows without altering the whole > application a lot. > > To make things a bit clearer, this is what I wanted to achieve: > > test.exe needs to remain the executable but also export some symbols: > foo_help and foo_hello > > Needed to create a import library for these symbols (libtest.a) and > allow plugin.dll link to it > > Every time tried using extern and export these symbols ended with > unresolved references to foo_help and foo_hello, even when libtest.a > contains those definitions. > > Also tried with __cdeclspec(dllexport) and __cdeclspec(dllimport) in > test and plugin respectively without avail. > > As I've been suing dynamic languages for quite long, I'm definitely > getting rusty at C. > > Does anyone have a hint to achieve this without radically altering the > original program? > > Thank you. Hello, you should use a callback to set a pointer to your function in your executable. You don't need to link to your executable. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAkzDA/cACgkQp56AKe10wHfmSgCcDDeCT3/fzzxvk9GGA5GpWRvI epIAoIIvI5JtiR6SuYV5QP9o12hb+tBY =cAYg -----END PGP SIGNATURE----- |
From: Luis L. <lui...@gm...> - 2010-10-23 17:50:50
|
On Sat, Oct 23, 2010 at 12:49 PM, JonY <jo...@us...> wrote: > > Hello, > > you should use a callback to set a pointer to your function in your > executable. > > You don't need to link to your executable. Understood JonY, and is the same answer you gave me over #mingw. But the problem is that doing that way will require extensive modifications on how plugins are compiled and how the main program is compiled too. These differences will make hard keep a portable way, as these plugins might be compilable under Linux/OSX or even cross-compiled for Windows. Seems that the only path is modifying the program to generate a shared library to link against it. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry |
From: JonY <jo...@us...> - 2010-10-24 01:01:56
Attachments:
0xED74C077.asc
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/24/2010 01:50, Luis Lavena wrote: > On Sat, Oct 23, 2010 at 12:49 PM, JonY <jo...@us...> wrote: >> >> Hello, >> >> you should use a callback to set a pointer to your function in your >> executable. >> >> You don't need to link to your executable. > > Understood JonY, and is the same answer you gave me over #mingw. But > the problem is that doing that way will require extensive > modifications on how plugins are compiled and how the main program is > compiled too. > > These differences will make hard keep a portable way, as these plugins > might be compilable under Linux/OSX or even cross-compiled for > Windows. > > Seems that the only path is modifying the program to generate a shared > library to link against it. Relying on platform features such as having undefined symbols in an executable is already non-portable. Linking the executable to the DLL defeats the purpose of using a DLL. You would have to relink every time you wanted to use your DLL with another executable. You can just implement some sort of get/set method to setup your callbacks. See <http://www.newty.de/fpt/index.html> for more details on how to use function pointers. Another way to solve the dependency issue is to use LoadLibrary and GetProcAddress. Something like: Hdll = LoadLibrary("Myexe.exe"); functionpointer = GetProcAddress(Hdll, "MySymbol"); functionpointer(); It is similar to unix dlopen and dlsym. LoadLibrary and GetProcAddress usage info: <http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx> <http://msdn.microsoft.com/en-us/library/ms683212%28v=VS.85%29.aspx> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAkzDgSwACgkQp56AKe10wHcOQgCglPf4tBMYFoh6Z6M6qMffucXv 6bUAnRUnZBz5oS0WCqUqBtsUmSGH93YJ =pvwY -----END PGP SIGNATURE----- |
From: Cesar S. <ces...@gm...> - 2010-10-23 20:51:47
Attachments:
plugin_test.tar.gz
|
On 10/23/2010 01:39 PM, Luis Lavena wrote: > I was attempting to port a program from Linux to Windows where certain > functions are exported and used by plugin/extensions. Since the > program is not a shared object, there is no import library to link > with. Dear Luis, Please find attached an example I made some time ago while answering a similar question. 1. Each plugin calls a function bar() that is in main.cc. 2. The interface in the plugin is done by the constructor of a static object, which sets the global "x" to point to it. Expected result: ./a.out.exe ./my_dll.dll 89 ./a.out.exe ./my_other_dll.dll 130 Hope this helps, Cesar |
From: Luis L. <lui...@gm...> - 2010-10-26 21:19:05
|
On Sat, Oct 23, 2010 at 5:51 PM, Cesar Strauss <ces...@gm...> wrote: > On 10/23/2010 01:39 PM, Luis Lavena wrote: > >> I was attempting to port a program from Linux to Windows where certain >> functions are exported and used by plugin/extensions. Since the >> program is not a shared object, there is no import library to link >> with. > > Dear Luis, > > Please find attached an example I made some time ago while answering a > similar question. > > 1. Each plugin calls a function bar() that is in main.cc. > 2. The interface in the plugin is done by the constructor of a static > object, which sets the global "x" to point to it. > > Expected result: > ./a.out.exe ./my_dll.dll > 89 > > ./a.out.exe ./my_other_dll.dll > 130 > > Hope this helps, > Thank you Cesar. This helped me be able to export the symbols properly and also link the extensions/plugins against the import library. I've also tested adding more symbols without the need to recompile the extensions/plugins and seems to be working properly. Once again, thank you for your time and example. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry |