From: Colin W. <wa...@re...> - 2004-11-11 20:58:40
|
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. |