GNOME Bugzilla – Bug 51833
ABI dependent module directories
Last modified: 2011-02-04 16:09:21 UTC
While building gtk+/1.2.9 for SGI IRIX 6.2 I noticed one bug and one misfeature. They overlap, so they're in the same patch, but the bug is the diff a the very end: path is free'd twice if g_get_home_dir() fails. The misfeature is that there are still places where "/lib" is hard-wired into paths. Since IRIX supports three different ABI, with "lib32" being the default, someone will someday get into trouble with this. Here's the patch: --- ./gtk/gtkrc.c Fri Feb 2 12:03:19 2001 +++ ../gtk+-1.2.9/./gtk/gtkrc.c Mon Mar 5 13:57:10 2001 @@ -39,6 +39,17 @@ #include "gtkthemes.h" #include "gtkintl.h" +#define ABILIB "lib" +#ifdef _MIPS_SIM +# if (_MIPS_SIM == _MIPS_SIM_NABI32) +# undef ABILIB +# define ABILIB "lib32" +# elif (_MIPS_SIM == _MIPS_SIM_ABI64) +# undef ABILIB +# define ABILIB "lib64" +# endif +#endif + typedef struct _GtkRcSet GtkRcSet; typedef struct _GtkRcNode GtkRcNode; typedef struct _GtkRcFile GtkRcFile; @@ -245,7 +256,7 @@ var = getenv("GTK_EXE_PREFIX"); if (var) - path = g_strdup_printf("%s%s", var, "/lib/gtk/themes/engines"); + path = g_strdup_printf("%s%s", var, "/" ABILIB "/gtk/themes/engines"); else path = g_strdup_printf("%s%s", GTK_LIBDIR, "/gtk/themes/engines"); @@ -287,7 +298,7 @@ var = getenv("GTK_EXE_PREFIX"); if (var) - path = g_strdup_printf("%s%s", var, "/lib/gtk/themes/engines"); + path = g_strdup_printf("%s%s", var, "/" ABILIB "/gtk/themes/engines"); else path = g_strdup_printf("%s%s", GTK_LIBDIR, "/gtk/themes/engines"); module_path[n++] = g_strdup(path); @@ -294,11 +305,12 @@ g_free(path); var = g_get_home_dir (); - if (var) - path = g_strdup_printf("%s%s", var, "/.gtk/lib/themes/engines"); - module_path[n++] = g_strdup(path); - module_path[n] = NULL; - g_free(path); + if (var) { + path = g_strdup_printf("%s%s", var, "/.gtk/" ABILIB "/themes/engines"); + module_path[n++] = g_strdup(path); + module_path[n] = NULL; + g_free(path); + } } static void
Fixed the bug, will be in 1.2.10. The ABILIB stuff is the same as at least #50077, and I think there is another version of this patch that you submitted to ftp.gnome.org that will have been moved to the bug tracker somewhere but I can't find. (At least, it looks very familiar) I don't like the ABILIB patch much because it puts system-specific #ifdefs in the C files and breaks compatibility with existing theme installations on IRIX. But beyond that, I don't really understand it: GTK+ will install (AFAIK) identically named libraries in $(libdir) == $(exec_prefix)/lib for both ABIS. So, if you want GTK+ compiled against both ABIs, you need two exec_prefix's. Now, I suppose if you are setting GTK_EXE_PREFIX or installing themes in ~/.gtk/lib, and then running mixed ABI GTK+ programs, it would matter, but really, people don't set GTK_EXE_PREFIX or ~/gtk/lib on any platform, so I don't think this is much of an issue. Since there are other issues with at least the GTK_MODULES environment variable, I don't think this is something we can address in 1.2.x at this point.
Yes, I set --libdir for each ABI I build, but use a common --prefix. I'm undoubtedly making a bigger deal out if this than it is, but basically I'm worrying about what will happen when someone has a mix of -n32 and -64 applications installed. Whatever is in ~/.gtk/lib will be the wrong format for something. Writing individual wrapper scripts for each app would be a pain, since there is no global GTK_EXE_PREFIX variable setting that's right for all situations. Compiling libgtk+ with distinct --prefix or --libdir doesn't help because the environment variables are still common, as are paths in the user's home directory. The patches are trying to make it so that an -n32 app will use a different path than a -64 app for finding shared libraries. To reduce culture shock I used the same convention as IRIX itself. An alternative to system-specific #ifdefs would be to make ABILIB a config variable, like LIBDIR. Heck, just let it default to "lib" everywhere, and I'll manually force it when I do my builds! That might also help the compatibility issue since only the IRIX Freeware builds would support multiple ABIs simultaneously. But I'm not sure that merits leaving this hole open on default builds. I'm not sure how to fix GTK_MODULES. I've never liked the IRIX solution of using multiple parallel environment variables (e.g. LD_LIBRARY_PATH, LD_LIBRARYN32_PATH, and LD_LIBRARY64_PATH), but maybe that's the right solution here. Sigh, what a lot of bother. Thanks, David PS: The double-free of path at the end should really be a separate bug report. It just happens to overlap this diff.
*** Bug 50077 has been marked as a duplicate of this bug. ***
Fix for 68474 makes GTK+ search in a directory depending on the host from configure when loooking for modules, then in the main directory. This should be sufficient to solve this problem, though some manual juggling of file locations may be needed on install. [GTK+ doesn't install it's files in host-architecture dependent location becuase most people don't need the feature, and it's quite possible to get the host architecture changing as details of the system change, so it could cause problems with people losing their modules ]