[gst-devel] [RFC][PATCH] GStreamer multilib support

[Colin Walters]

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
user, obviously. 

> 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.