> I'm wondering how to check the runtime version of the (glib and gtk for > example) DLLs, that the application is linking to.
You mean check at run-time? Using the API provided for that, if any. For GLib, use the glib_major_version, glib_minor_version and glib_micro_version variables (which are exported from the DLL). For GTK+, correspondingly gtk_major_version, gtk_minor_version and gtk_micro_version. For Pango, use the function pango_version() and then split it up into major, minor and micro version numbers using the expressions pango_version()/100/100, pango_version()/100%100 and pango_version()%100. Or do you mean check before running? Then your are on the wrong track. There is nothing in the Windows executable format that would say what *version* of a DLL an executable (an EXE or DLL) links to. Just the DLL name is specified. > I know one can check the version of included headers and statically linked > libraries using GLIB_MAJOR_VERSION and glib_major_version, but the dynamic > linking is giving me trouble. glib_major_version etc works fine also for DLLs, as long as you just include the appropriate headers that declares the variable correcly as dllimport. If you just write "extern int glib_,major_version:" in your code and don't use the GLib headers, you might (depending on compiler) actually access the so-called import stub linked in from the import library, not the real exported variable in the DLL. (Although with a current mingw toolchain, it seems to work fine also to leave out the dllimport declaration.) (Complications like this is one reason why having variables (as opposed to functions) in a library API is not recommended.) > Or maybe the only way is to actually place the required DLLs in the > application directory (the workaround I'm now using)? For applications installed by an installer on end-user systems, that is indeed the recommended way. Attempts to share GTK+ stack installations between unrelated applications developed and distributed by unrelated parties is not a good idea on Windows (or Mac OS X for that matter). In an ideal world, sure, it would be the right thing, but this isn't an ideal world. For a development system, you just need to know what you are doing and keep track yourself of what you have where and what your PATH is in any shell or other process... Not really that different from doing development on a Linux system with several versions of some shared libraries installed and manipulating LD_LIBRARY_PATH to test against them. > If so, then how do I know which files are actually required? You mean *required*, or *used*? For all DLLs in the GTK+ stack, the overall rule is simple: the DLL version required is the one compiled against, or newer. if the DLL name is the same, the DLLs are backward compatible. I.e. you can run against a newer version even if the code has been compiled against an older version. Of course, occasional regressions in some corner cases make matters more complicated: it might be that some software works better with an explicit old version than with newer ones. To know which DLLs are used at run-time, familiarize yourself with the rules for DLL lookup. Read http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx . Especially note that the system and Windows directories are searched before the directories in PATH. That's why one should never, ever, install 3rd-party DLLs in these directories (typically \windows\system32, \windows). --tml _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
