[gst-devel] [RFC][PATCH] GStreamer multilib support
walters at redhat.com
Thu Nov 11 12:59:07 CET 2004
On Thu, 2004-11-11 at 12:02 -0800, David Schleef wrote:
> On Thu, Nov 11, 2004 at 02:06:04PM -0500, Colin Walters wrote:
> > > So, the patch should at the very least look at these tools, and use the
> > > same mechanism to determine lib-ism and then use the correct version of
> > > everything.
> > Hm, I'm not sure what you mean. How would say gst-launch know whether
> > you want to use your 32 bit plugins or your 64 bit plugins?
> With a command line switch.
If by this you mean having a shell script wrapper that looked for --i686
or --x86_64 on the command line and exec'd gst-launch-i686 or gst-
launch-x86_64 respectively, that might be doable. But trying to
implement it in one binary I think is nearly impossible - you'd be
loading 32-bit code into a 64-bit executable, or vice versa.
> I'm mostly opposed to this patch. Attaching an architecture prefix
> (or infix) to a command name is just silly. Do you plan to do the
> same with totem? gst-launch (and friends) are effectively the same
> as totem -- they are just applications.
Not exactly. gst-inspect for example is very useful to have for both 32
bit and 64 bit modes. It's a developer tool. gst-launch is definitely
more a fuzzy area.
For true end user applications, the assumption is simply that 64 bit is
preferred if installed. So distributors have to make a choice. For
example, with Mozilla on x86_64, 32 bit plugins won't work.
Distributors simply have to make a choice of whether they want a 64 or
32 bit mozilla. It doesn't make sense to punt that choice to the end
> gst-register is somewhat
> different, of course. If you really want to install multiple
> copies of gst-launch, install them in different prefixes.
I don't see how different prefixes helps the user any more.
More information about the gstreamer-devel