Peter Bergner writes: > Albert D. Cahalan wrote: >> Why: >> Somebody thought it was a good idea for a 64-bit >> system to have all the apps be 32-bit. > > As one of the people that made the decision that the > majority (not all) apps be 32-bit, I can say without > hesitation that it was the right choice!
You sure did make a mess for library developers. The Alpha is trivial to support. >> This means that a 32-bit app has to use larger >> and slower data types to handle some of its data. > > This is only true if you want one binary which can > run on both systems and it needs the larger data types. > There is nothing stopping you from creating two binaries, > one for 32-bit kernels and one for 64-bit kernels. Excellent. How do I do it? This would be ideal: 1. plain 32-bit procps for a 32-bit kernel 2. plain 64-bit procps for a 64-bit kernel 3. special 32-bit procps library for a 64-bit kernel Regular ppc gets #1, while ppc64 gets #2 and #3. > If you have a problem with common binaries (for the very > very very few apps that it even matters), you need to > talk with the application programers, since the changes > to apps like "top" are not forced on you by our decision > to execute 32-bit apps on our 64-bit kernel. Well, I'm the application programer in this case. There's a library too, in need of a stable ABI. http://procps.sf.net/ I can't find documentation for... a. How do I force gcc into 64-bit mode? b. How do I force gcc into 32-bit mode? c. How do I tell if a 32-bit build is meant for ppc64? d. Where do I install a 64-bit library? e. Where do I install a 32-bit library? f. How do I prevent a plain 32-bit lib from running on ppc64? g. Can I handle ppc64 and mips64 the same way? Coolness would be a thunking feature, so that a 64-bit library could provide 32-bit entry points. BTW, I could use an account on such a machine. Even a plain user account would be helpful.
