On Sat, 3 Nov 2007, al davis wrote: <snip>
>In the real file, there are hundreds of symbols needing >lazy resolution. There are also hundreds of dll's being built. >The program can not know anything about the dll's, >other than the calling mechanism, which is really C++ >virtual functions, with a dispatcher. It is working great >on Linux now. > >Are you telling me that Windows cannot do lazy resolution? In my experience, with DLLs, dynamic means you need to know all symbols on compile time and even more, where each symbol is coming from. Using -l everywhere this more or less fits, but for example you can not easily write an a.dll that depends on b.dll that in turn depends on a.dll since you couldn't load them. Things become much funnier when you want to use dlopen(). For example you want to write a plugin that will be loaded runtime and it will automaticly find symbols defined in the host application or other plugins. On *NIX, if you use lazy linking and RTLD_GLOBAL then you just need to make sure all the dependant .so are already dlopen()'d by the time you load your plugin. When you compile your plugin, you don't need to explain the system where the symbols will come from. In case of libgpmi this could have been a showstopper, since it heavily depends on the plugin loading described above. Our solution for the problem is dl-compat[1], a dynamic linker replacement for win32 that is compatible with dlopen() (including lazy, RTLD_GLOBAL and others). Igor2 [1] dl-compat is accessible at svn://svn.libgpmi.org/gpmi/branches/dl-compat under the LGPL _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
