CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 10 of 10

Hybrid View

  1. #1
    Join Date
    Sep 2009
    Posts
    19

    [RESOLVED] accessing symbols in appllication from within dynamic library MinGW

    Hi,

    I am porting an application from Linux to Windows. Since it is a GTK app most of the stuff works; I have to touch a little here and there. One problem though I cannot find the solution as it seems. The application uses a plugin system for easy expandable functionality. The interface to the plugin is very simple: an init function, a worker function, and a deinit function. The plugins shall have access to the main applicationsymbols (functions global variables). I cannot find a working (and feasible) way under Windows to make the linking work. I always get "undefined reference" errors for symbols which exist in the application.
    I am using MinGW 4.6.2.
    I made a stripped down demo application to be able to better (and faster) test the principle. I am using the dlfcn-win32 project from Ramiro Polla (http://code.google.com/p/dlfcn-win32/) for the dynamic loading stuff and it works like a charm.

    Here is the project:
    plugintest.tar.gz
    plugintest.zip

    It tried a number of commandline options to the linker for the application (--export-all-symbols, --export-dynamic, -rdynamic (apparently not supported in MinGW)) as well as for the shared objects (--allow-shlib-undefined, --enable-auto-import, --enable-runtime-pseudo-reloc).

    As you can see in the provided makefile under Linux it is just "-shared" for the .so. Under Mac OS X (Darwin) it is "-bundle -bundle_loader <app name>".

    I googled a lot but most of the suggested solutions just did not work. Either it is a different configuration / environment or I must have overlooked something.

    Does anyone here know how to do this and if it is even possible in Windows?

    Many thanks in advance!

    Johannes

    Edit:
    Here is a .zip archive of the dlfcn stuff with modified makefile, which works on the cmd.exe command prompt; MSYS is not required. Just adjust the MinGW installation path in config.mak and type 'make" and 'make install'.
    dlfcn-win32-r19.zip

    Thanks for your efforts,
    Johannes
    Last edited by johanneshau; April 18th, 2013 at 05:18 AM.

  2. #2
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: accessing symbols in appllication from within dynamic library MinGW

    You may want to attach your project (in zip archive) to your post.
    Victor Nijegorodov

  3. #3
    Join Date
    Sep 2009
    Posts
    19

    Re: accessing symbols in appllication from within dynamic library MinGW

    Quote Originally Posted by VictorN View Post
    You may want to attach your project (in zip archive) to your post.
    I added a .zip archive to the original post.

  4. #4
    Join Date
    Nov 2003
    Posts
    1,902

    Re: accessing symbols in appllication from within dynamic library MinGW

    Windows does not support "automatic reverse dynamic linking" - or in other words, what you get on Linux when the app is compiled with "-rdynamic" (or "--export-dynamic").

    You should be able to "__declspec(dllexport)" symbols in your EXE - then the plugins programmatically link to those symbols via GetProcAddress().

    gg

  5. #5
    Join Date
    Sep 2009
    Posts
    19

    Re: accessing symbols in appllication from within dynamic library MinGW

    Quote Originally Posted by Codeplug View Post
    Windows does not support "automatic reverse dynamic linking" - or in other words, what you get on Linux when the app is compiled with "-rdynamic" (or "--export-dynamic").

    You should be able to "__declspec(dllexport)" symbols in your EXE - then the plugins programmatically link to those symbols via GetProcAddress().

    gg
    I read about these "dllexport" declarations and I would give it a try for a new, Windows-only project, but for my porting project this is not an option (I hope there will be another), since I cannot add a "__declspec ..." declaration to all of the symbols I might want to use in (future) plugins. Furthermore the plugins are not (yet) full-blown dlls, they are just object files linked with the "-shared" flag.
    But thanks anyway!

  6. #6
    Join Date
    Nov 2003
    Posts
    1,902

    Re: accessing symbols in appllication from within dynamic library MinGW

    You can omit the "dllexport" by linking the main EXE with "-Wl,--export-all-symbols", which which will export all global symbols.

    I'm not sure if you can bypass having to call GetProcAddress() in the plugin in order to "link" to those exported symbols. Unless you can generate an import-lib for the EXE's exported symbols. But then the plugins will only work with that EXE name (if its even possible).

    gg

  7. #7
    Join Date
    Sep 2009
    Posts
    19

    Re: accessing symbols in appllication from within dynamic library MinGW

    Quote Originally Posted by Codeplug View Post
    You can omit the "dllexport" by linking the main EXE with "-Wl,--export-all-symbols", which which will export all global symbols.

    I'm not sure if you can bypass having to call GetProcAddress() in the plugin in order to "link" to those exported symbols. Unless you can generate an import-lib for the EXE's exported symbols. But then the plugins will only work with that EXE name (if its even possible).

    gg
    I tried "-Wl,--export-all-symbols" already; it did not work. I am using the dlfcn library from Ramiro Polla, which wraps the Windows API calls to the POSIX dlopen()/dlsym()/dlclose() calls. dlsym() uses GetProcAddress() and it works as far as I can test it. The thing which does not work - and the error is at link time - is when I try to reference any objects from the main executable.
    I already tried to generate an "export library" (.lib, .def files) of the application but this did not help either. But I have to admit that the various .lib/.def/.a/.dll libraries are rather confusing to me and I am all but firm in dealing with them.
    What did work was when I generated a DLL of my applpication. Then the linking of the plugins went OK, but - as I suspected - at runtime the objects were different in the DLL than in the application. Furthermore the DLL had to be present. This behaviour is clear to me and not what I want to use.

    I am sure it is just an option to the linker but the documenation I found so far is not clear to me.

    Thanks anyway!

    Johannes

  8. #8
    Join Date
    Nov 2003
    Posts
    1,902

    Re: accessing symbols in appllication from within dynamic library MinGW

    If you can't get an EXE-import-lib to work (I'm not sure if it is possible), then you're down to two options:
    1) Manually link the EXE's symbols with GetProcAddress() (or through dlfcn-win32)
    2) Turn the EXE into a DLL that exports a "Main()" along with the needed plugin symbols. Then a simple EXE-wrapper that loads and calls "Main()".

    gg

  9. #9
    Join Date
    Sep 2009
    Posts
    19

    Re: accessing symbols in appllication from within dynamic library MinGW

    Quote Originally Posted by Codeplug View Post
    If you can't get an EXE-import-lib to work (I'm not sure if it is possible), then you're down to two options:
    1) Manually link the EXE's symbols with GetProcAddress() (or through dlfcn-win32)
    2) Turn the EXE into a DLL that exports a "Main()" along with the needed plugin symbols. Then a simple EXE-wrapper that loads and calls "Main()".

    gg
    Thanks again for your time.
    You gave me the right hint: I have to manually load the addresses of the symbols I want to use within the plugin in the plugin, best in the init_plugin() function. This adds a little code in the init_plugin() function and a few #defines at the top of the file, but this is tolerable.
    Thanks a lot!

    Here is the working test app:
    Attachment 31339

  10. #10
    Join Date
    Sep 2009
    Posts
    19

    Re: accessing symbols in appllication from within dynamic library MinGW

    It turned out that in the real application the declarations and manual loading stuff were quite involved (sometimes more code thatn the actual plugin ...). So I came up with some preprocessor stuff, which reduces the necessary typedefs etc. to a tidy minimum.

    Here is the resulting project:
    plugintest.zip

    Thanks again for helping!

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured