Roland Mainz wrote:
>
>
> Please read the RFE again - it is needed for development of applications
> which should support both 32bit+64bit systems (and just trying to "fix"
> the matching build systems is hopeless - it's like trying to boil the
> oceans. You can't fix each instance of autoconf&co.) and to handle cases
> where only 32bit applications are suiteable for a task (e.g. if a plugin
> is needed where the required libraries are only available as 32bit
> binaries). Right now the only "workaround" is to become the "root" user
> and move the matching binaries around.
>
I see a problem with this assertion:
Either:
1) the application works on 32-bit, and hence doesn't need the 64-bit tools
2) the application does not work on 32-bit and needs 64-bit tools
I recognize that there are *some* applications which perhaps can perform
better on 64-bits, perhaps supporting larger data sets or somesuch. But
the fact that the application's behavior is inconsistent going from 32-
to 64- without any obvious way for the end user to realize the cause of
the difference gives me a bit of a pause.
I still think I'd recommend that the case be pruned back to delivering a
/usr/bin/64/bash (or somesuch) which is *available* to consumers, but
doesn't make it used by default. Then, developers which *need* it right
now at least have a recourse. (Most likely, the most pressing consumers
for this already know they need 64-bit support.)
Follow up case work can be done to investigate the possibility of use of
isaexec() (or hopefully a better mechanism yet to be designed) to pick
the best binary for the platform.
In other words, I think the project team shouldn't be afraid to tackle
this problem by baby steps.
-- Garrett
