Re: bloat tolerance?
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.
Reply to: