Roland Mainz wrote:
> 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).
>
The paragraph above describes a goal that goes far beyond the original
stated intent of this case, and would need to be backed by a full case.
Completely inappropriate for a fast track. If you want to switch to
64-bit binaries across the board on 64-bit platforms (or even have that
as a stated goal), then the intent needs to undergo a separate full review.
Please clarify.
-- Garrett
Btw, if we are only talking about one or two utilities, then the binary
additions and packaging changes are fairly modest. Probably doable in
less than hour. The *testing* changes are not that large. I still
think baby steps here are more appropriate than boiling the worlds
oceans at once.
> ----
>
> Bye,
> Roland
>
>
