GNOME Bugzilla – Bug 157867
[PATCH] multilib support
Last modified: 2006-01-12 10:08:49 UTC
Hi, This patch adds support for parallel 32/64 bit installations. See: http://sourceforge.net/mailarchive/forum.php?thread_id=5929366&forum_id=5947
Created attachment 33640 [details] [review] 32/64 bit parallel install
No controversy is a bit short, I just didn't look yet. Are you sure this is ok? At least you shouldn't use cpu (i686) but arch (i386).
There is, as far as I know, no portable definition of architecture. You'd have to have a database of CPU compatibility in autoconf, and I don't think they wanted to do that. It could try to call out to RPM or dpkg or whatever, but...yeah.
Setting milestone to next release so it will be reviewed for inclusion then.
I think this should be WONTFIX. If you want to have binaries for different architectures, install them into a different prefix or use configure renaming options. Unless of course there's a common agreed on way to do this. How do glib and friends do this? (I can come up with at least gdk-pixbuf-query-loaders that has the same issue, maybe gtkdoc-scan, too)
Can't you just use ./configure --program-transform-name='s,$,-arch,' ?
Benjamin: Currently at least the Fedora package of GTK+ has a patch which is similar conceptually; but I think this patch is better in that /usr/bin/gst-register still works, but gdk-pixbuf-query-loaders requires you to pass the architecture name. Longer term, Owen wants to move the cache files into the actual directory, instead of storing them in /etc. The most important part of this patch by far is gst-register; we need separate versions of those for caching the separate library directories. As for using program-transform-name...that might allow us to avoid hardcoding binary name transformations in Makefile.am, but we still need to have separate registry.xml files for 32-bit and 64-bit plugins.
The registries are already in different locations because GST_CACHE_DIR is different. However, for other reasons (NFS-mounted home directories), we should use .gstreamer-0.8/registry-${arch}.xml for the user registry.
Why would GST_CACHE_DIR be different? It's defined as: "${localstatedir}/cache/gstreamer-$GST_MAJORMINOR", i.e. /var/cache/gstreamer-0.8.
Mike Hearn mentioned here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143312 that transforming the names breaks gst-launch-ext. Thinking about it I'm inclined to just move the gst-register executable, and keep gst-launch and friends unchanged. Would that make the patch more palatable?
GST_CACHE_DIR is different because you used --with-cachedir=/var/cache/gstreamer-0.8-somearch. Did I forget to mention that? gst-launch should probably be fixed to understand $(program_transform_name). gst-register should arguably be installed in $(libexecdir), but as a long-time SysV user, I find this evil.
Created attachment 35796 [details] [review] lib64 patch For NFS-mounted homedirs, it seems to me that even registry-${arch}.xml isn't sufficient; you need registry-${arch}-${machine}.xml, no? Since different systems can have different sets of plugins installed. But anyways, here's an updated patch which only moves gst-register to /usr/libexec and suffixes it with an architecture, and adds the architecture to the registry files.
The point of installing into libexecdir is that the directory should already be versioned.
What do you mean by versioned? The problem being solved is multiarch compatibility.
heh, yeah. I meant that. Presumably, $(libexecdir) becomes /usr/lib64exec or something.
No, there is no /usr/lib64exec; this would break 32-bit applications which want to execute helper programs; e.g. gnome_segv2.
any news here ?
this can basically be closed for 0.10, because: - gst-register does not exist anymore - no global cache file gets written anymore - only a user one, in the user's home dir - that registry gets named registry.${arch}.xml So unless I'm missing something, everything should now work with multilib (tested) and NFS home mounts (untested)