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;)
