[MPlayer-dev-eng] [PATCH] Paths for x86_64

[D Richard Felker III]

On Thu, Dec 30, 2004 at 11:15:38PM +0100, Christof Buergi wrote:
> > > a) a pure 64bit operating system with encapsulated 32bit
> > > applications is cleaner then a hybrid system, but impractical.
> > this is nonsense. why would you need any 32bit apps whatsoever?? just
> > recompile.
> 
> First off, there are applications with no open source alternative. Some 
> of the Windows-Codecs that MPlayer uses, for instance. Another problem 

This is not a reason to compile MPlayer as a 32bit app. Instead
someone who cared about win32 crap should just enhance MPlayer's win32
loader to be able to call 32bit windows code from the native 64bit
MPlayer binary.

> are applications that have not been written with portability in mind. 
> Those may break when recompiled for 64bit. Trust me: There are such 
> applications. Otherwise, we wouldn't have had that discussion.

Then patch those applications. They are very few, and they need to be
patched anyway.

> > > b) usability is more important then ideology.
> > this is not usability vs ideology. it's short-term hacks versus
> > long-term usability. adding hacks to every program to make it install
> > libs in lib64 if arch==x86_64 is totally impractical and not usable.
> 
> Well, the people on our list still found it more user friendly to change 
> a few makefiles (which is usually done by the package maintainers), 

This is the idiotic distro-centric way of thinking. I have no respect
for it. The same line of thinking is why every release of Linux,
glibc, etc. is buggy and does not work out of the box: they expect the
distro to fix all the broken crap, and then it does not work for
people without distros. The upstream source should ALWAYS be the one
to release working, non-broken source that compiles and installs
correctly on any system.

> then putting every single one of those special applications that they 
> only got as a 32bit binary in a chroot jail. And I doubt that those 
> applications will go away in a hurry.

I never said anything about chroot/jail. Unless the app is very stupid
and hard-codes lib paths in the binary, just modifying the libary
paths in the 32bit dynamic linker will do the trick.

> >> c) a pure 64bit system for x86_64 is not necessarily the best
> >> solution, as the Opteron/Athlon64 is not a pure 64bit CPU, and the
> >> Xeon with x86_64 support is no 64bit CPU at all.
> > huh? this is an idiotic windoze-like way of thinking.
> 
> Let me put this another way: Many do look at the Opteron not as a 64bit 
> CPU, but as a 32bit CPU with a 64bit extension. In fact, many 

I understand this. It's as stupid as when Microsoft looked at the 386
as a 32bit extension to a 16bit cpu (Windows 3.x). These people are
stupid and should not be making the decisions that will bog Linux down
for the next 5 years with backwards compatibility crap.

> applications don't run faster in 64bit mode and don't use more than 4GB 
> of RAM, so why bother adapting them to 64bit? The Opteron's ability to 

./configure && make is not what I call adapting...

> run 64bit code and 32bit code natively at the same time is the one 
> reason that makes it so much better accepted than the Itanium. Why 

Only for windows/pc users. For everyone else it makes no difference.

> should we throw that away? Backwards compatibility lately got a bad 
> name, but it still is considered to be an advantage, not a 
> disadvantage.

I appreciate the backwards compatibility, because for the time being I
can use an athlon64 system as just a fast x86, and in the future
rebuild all software on it for x86-64 once the bugs are worked out and
I have a decent compiler for x86-64 (gcc3 is not decent). But making a
hubrid system is just incredibly ugly and stupid.

> > i don't care. supporting lib64 is the business of the distributor if
> > they want that crap, NOT the responsibility of every single software
> > author.
> 
> Normally I would agree, but MPlayer is special. It's users are (heavily) 
> encouraged to get the software from here, not from the distributors. 
> Thus, listening to what the user wants might not be such a bad idea at 
> times. Today, every single x86_64 distribution I know of except Debian 
> is using the lib64 approach, and Debian isn't representing the majority 
> of the community.

Debian is the only sane distro with x86-64 support. The others all
suck. I knew this long before hearing about the lib64 crap, btw.

> To shun lib64 altogether or to have an option "use 
> lib64 paths (for broken systems)" is actually like saying "every distro 
> but Debian is broken". I'm afraid that would be very ill received.

Well it's true. And that is what we will do. End of discussion.

Rich