Rick Jones writes: > http://developer.gnome.org/doc/API/2.0/glib/glib-Dynamic-Loading-of-Modules.html#g-module-build-path > which reads: > > For example, calling g_module_build_path() on a Linux system with a > directory of /lib and a module_name of "mylibrary" will return > /lib/libmylibrary.so. On a Windows system, using \Windows as the > directory it will return \Windows\mylibrary.dll. A documentation bug! Thanks for reporting. > Might be good to flesh-out the examples a bit and explain the whole thing. > Since g_module_open knows how to deal with .la files, should > g_module_build_path() special case seeing a .la at the end of the > module_name? Probably yes. But really, the g_module_build_path() function is IMHO not that awfully useful. What would be more useful would perhaps be was a function like g_module_open_from_directory(const char *directory, const char *module, GModuleFlags flags) which on Windows would actually try both with and without the "lib" prefix. Or maybe the existing g_module_open() should just be extended to do that, i.e. even if you pass it x:\foobar\zap.dll it would also try x:\foobar\libzap.dll if zap.dll wasn't found. (cygzap.dll on Cygwin) --tml _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list