Bug#406453: 32bit libgtk2.0 must use /etc/gtk-2.0/gdk-pixbuf.loaders.32

[Goswin von Brederlow]

Loïc Minier <lool+alioth at via.ecp.fr> wrote:

>On Wed, Jan 17, 2007, Goswin von Brederlow wrote:
>> To get ia32-libs-gtk working properly chunks 1+2 of the patch need to
>> be applied. Chunks 3+4 just round things up by allowing the admin and
>> user to have different gtkrc files if they so choose.
>
> I've started looking into the problem last week, and it's relatively
> complex.  Actually, for module pathes, Gtk will try plenty of pathes
> (as you might have seen in straces), so either we support a diversion
> of all of these (such as /etc/gtk-2.0/$host => /etc/gtk-2.0/$host.32),
> or we simply advice people to move away of these pathes (by default, a
> path including the triplet is checked).

I don't see that in the logs. I only see:

32bit acroread:

access("/home/mrvn/.themes/Raleigh/gtk-2.0/gtkrc", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/themes/Raleigh/gtk-2.0/gtkrc", F_OK) = 0
open("/etc/gtk-2.0/gdk-pixbuf.loaders", O_RDONLY|O_LARGEFILE) = 4
open("/etc/gtk-2.0/gtk.immodules", O_RDONLY|O_LARGEFILE) = 4

Seems like strace isn't showing lstats for 32bit code like below.


64bit gkrellm:

lstat("/etc/gtk-2.0/gtkrc", 0x7fffc5cd8a10) = -1 ENOENT (No such file or directory)
lstat("/home/mrvn/.gtkrc-2.0", 0x7fffc5cd8a10) = -1 ENOENT (No such file or directory)
access("/home/mrvn/.themes/Raleigh/gtk-2.0/gtkrc", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/themes/Raleigh/gtk-2.0/gtkrc", F_OK) = 0
lstat("/usr/share/themes/Raleigh/gtk-2.0/gtkrc", {st_mode=S_IFREG|0644, st_size=69, ...}) = 0
open("/usr/share/themes/Raleigh/gtk-2.0/gtkrc", O_RDONLY) = 6
open("/etc/gtk-2.0/gdk-pixbuf.loaders", O_RDONLY) = 6

I see one global rc file, one in home, the themes rc file(s) and then
the loaders/modules.

I see nothing host specific and nothing with the triplet. If gtk would
load its conffiles from a dir with triplet we wouldn't have the
problem.

>I've given some thought on how to handle this, and I don't want to spam
> all users with a fat NEWS.Debian, so I thought simply supporting
> diversions for what Debian ever shipped is enough
> (in /etc/gtk: gdk.loaders and gtk.immodules), and we shouldn't bother
> with supporting anything else at the code level, but this should be
> documented in README.Debian.
>   I think this is particularly true for ~/.gtk-2.0 modules as I can
> imagine users compiling an IM method if they need one.
>   I doubt changing the lookups in /usr/lib is useful, however I did not
> have time to look at all getenv calls to see whether or not some
> modules can be forcibly loaded without a full path via env vars.

I tried to be non-invasive with the patch and modeled it after the
pango change. Everything keeps working as is and only ia32-libs-gtk
uses the new dir to overload the normal path with the 32bit one.

> I'm not sure about handling of gtkrc, what made you customize this one?
> The possibility of loading modules from gtkrc?

You can have module paths in the gtkrc file. Unfortunately only for
modules, not for the loaders.

>> +# if defined (__i386__)
>> +      result = g_build_filename (GTK_SYSCONFDIR, "gtk-2.0", "32", "gdk-pixbuf.loaders", NULL);
>> +# else
>> +      if (! g_access(result, R_OK))
>
> I've collected patches from all other distros last week, and while they
> all use different names, I would prefer we use one of the existing
> names.
>
> Ubuntu:
>    GTK_SYSCONFDIR, "gtk-2.0", "gdk-pixbuf.loaders.32",

As shown for pango uname() is inconclusive to the point of
harmfullness.

Changing the GTK_LIBDIR seems completly unneccessary. The modules and
loader files contain the full path to the *.so files so this has no
affect at all. Could this work with relative paths? Because if it does
we could have it search through all libdirs till it finds a loadable
module. No more different configs per arch.

On other notes I find it a bit inconsistent to use _gtk_get_libdir()
to change the libdir but then not use _gtk_get_sysconfdir() as well
for the sysconf part. Probably because they used a .32 suffix instead
of a subdir.

> OpenSuse:
>    GTK_SYSCONFDIR, "gtk-2.0", "gdk-pixbuf64.loaders"

Intrusive to the build system and hardcodes everything to "64". This
would have to be conditionalized on the arch first.

> Fedora:
>    GTK_SYSCONFDIR, "gtk-2.0", HOST, "gdk-pixbuf.loaders"
>    (-DHOST=\"$(host_triplet)\")

For the final product this is the nicest but if we were to use this
now then multiarch packages would need to conflict with our hackish
ia32-libs-gtk. We stayed clear of that everywhere else.

> (BTW, Fedora uses a slightly nicer test:)
>    g_file_test (result, G_FILE_TEST_EXISTS)

If that is "nicer" I'm all for it. That is a simple change.

> The patches are attached.  My personal preference goes for the Ubuntu
> option, but the Fedora one might be the best as it re-uses a path which
> is already handled by Gtk, the only difference is that the path is
> preferred when present and no further path is used; this might be
> problematic with the default location of the loaders which we
> currently use, and it's too late to change it for this cycle.

As said above I see no path with host tripplet in the strace. The
problem with continuing would be that then it would find both 32bit
and 64bit. Not sure how well that would go over with gtk.

MfG
        Goswin