GNOME Bugzilla – Bug 656116
Expand paths in key locations
Last modified: 2018-05-24 13:16:59 UTC
Created attachment 193385 [details] [review] Patch to expand paths in key locations There are several places in the GLib code where it deals with paths. On Windows, paths can contain %VARIABLE% which references environment variable VARIABLE. Having those paths expanded for the user automatically is very helpful. It also has the much more useful implication that when other packages using GLib need to install, for example, modules or some such in their LIBDIR, that those packages can be configured to have LIBDIR set to something like %PROGRAMDATA%/gtk or whatever. This in turn means that GLib and other stuff will work on any system when installed as a shared component, regardless of how the user has changed things. Below is a patch to the current HEAD of master to do this. This should port back into 2.28 and 2.29 cleanly.
It's nice to see some energy going in to the Windows side again. However I'm not sure that I like this or see the need for it. - Expanding environment variables introduces the risk that some user has a bad variable set, maybe by a random package they installed a long time ago, causing weird unreproducible and untraceable errors. I think it should be avoided if there is another solution - Installing GLib or any other Gnome platform libraries as a shared component is not something that we recommend, because of the different versions that can exist. Application A can require a libglib-2.0.dll built by mingw against MSVCRT.DLL, while Application B could overwrite this with libglib-2.0.dll built by VC against MSVCRT9.DLL. Or more simply, Application B's installer could be out of date and install GLib 2.14 while Application A requires 2.28. The recommended practice for Windows applications is to distribute all dependencies with the application, which actually seems to be in line with what Microsoft recommend[1] Do you have any other use cases for the patch? [1] http://support.microsoft.com/kb/326922
Sorry the response took so long, for some reason this ended up in my spam folder. Yes there is a very strong use case, especially if it is not installed as a shared component. What this allows a user to do is configure with things like LIBDIR set to %PROGRAMDATA%/mygtkname etc, as stated in my original post. If you are not compiling for use as a shared comonent, you may make the variable something like %MYINSTALLLOCATION%/gtk, and ensure in your application startup and thus allow your package to be installed anywhere, and still have loadable modules, config files, translation files etc located correctly. Your concern about errant environment variables being set by other packages is valid, but unlikely to ever be a problem. especially if you make the environment variable name in your LIBDIR setting something application specific that the application controls at startup. Although the discussion about applications over-riding each other is orthogonal to the patch, the solution to the problem is extremely simple: use better DLL names. libtool's method of naming shared objects is seriously on crack and flat out wrong, for almost the exact reasons you described above. Since this is Windows and not Linux we have some liberty about naming and could easily name the DLL's something like glib228.dll or glib229.dll etc (which is more consistent with windows naming anyway - windows doesn't need things prefixed with lib the way UNIX does). That way if application B installs and is linked against glib 2.14 it uses glib214.dll, and application A can happily install its own glib228.dll. Problem solved. The issue about msvcrt.dll versus the other microsft CRT's is also somewhat moot if you use only glib functions. You only run into trouble when something from a different CRT passes things into glib. For example, if the main app uses MSVCRT10.DLL and does a malloc(), it should not pass that pointer to g_free(). If someone is mixing API's like that frankly they deserve any headaches they get.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/435.