On Mon, Oct 25, 2004 at 05:06:21PM +0200, Andreas Jochens wrote: > ia64 puts 64bit libraries in '/lib' and not in '/lib64'. > The FHS Version 2.3 summarizes the reason for this: > "IA-64 uses a different scheme, reflecting the deprecation of > 32-bit binaries (and hence libraries) on that architecture." > The same reason to put 64bit libraries in '/lib' and not in '/lib64' > is valid for amd64: 32-bit binaries are deprecated on amd64 and should > therefore no be in '/lib'.
Oops. So I'm wrong about ia64; sorry about that :-) > On sparc64, s390x and mips64 the '/lib64' directory may be useful, > because on those architectures 32bit binaries are usually faster > than 64bit binaries. Therefore those systems tend to use 32bit libraries > in most cases while 64bit libraries are used for special purposes, > i.e. those architectures mostly run "biarch" ports which are mostly > 32bit based. > > The amd64 case is different because 64bit binaries are usually faster > than 32bit ones on amd64 because of the larger number of available > registers for 64bit binaries. Therefore the native 64bit port > which does not use 32bit libraries at all makes sense for amd64. I really don't agree that doing this based on the performance issues makes sense. And you're wrong about mips64; the most efficient libraries on mips64 targets are usually n32, which live in /lib32 rather than the o32 binaries in /lib. I don't know about s390x. Or about ppc64, which does the same. > > > There have been many discussions on this subject. I prefer to show a > > > working solution before presenting a proposal to change an existing > > > standard or to establish a new standard. Standards should be taken from > > > working and proven solutions not vice versa. > > > > Yes, but radical departures from standards should be _talked about_. > > By people from more than one implementor of the standard; that's what > > makes them standards. > > I have to start somewhere. Take my wishlist report as a first > try at convincing a major distribution to go the right way. My point is that convincing one distribution is the wrong place to start. > Recompiling the whole distribution and showing that everything > works and trying to get people to use it might be even a better way of > convincing people than just talking. The subject has been talked to > death. Something has to be done _now_, while the amd64 port and amd64 > distributions in general are not yet widely used for production > purposes. Later it _will_ become difficult to change anything. It's already widely used for production, in the commercial enterprise distributions. Of course recompiling the whole distribution works; it's only a compatibility issue. So I don't understand what that is supposed to show. It's been talked to death _in the wrong place_. > Do you really count this patch as a "radical" departure from a > standard? Yes. I do not think the commercial distributions will provide a symlink for compatibility with Debian, unless there is official ABI documentation showing that this is the way to go. That's where you should start. Please, tell me - has anyone discussed this compatibility issue outside of Debian? -- Daniel Jacobowitz
