Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview]

[Roland Mainz]

Garrett D'Amore wrote:
> 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.

The trouble is that this increases the workload of a simple "make
OS/Net+SFWNV 64bit clean by switching to 64bit binaries on 64bit-only
platforms" by a factor of at least _three_ (delivering twice the number
of binaries, do the matching testing _and_ implementing packaging
changes (and the testing for it)). This is technically ARC'able but no
longer implementable for a single contributor (at least not if we intend
to crawl over both trees and clean them up).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)