<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 17, 2018 at 4:07 AM, K K Subbu <span dir="ltr"><<a href="mailto:kksubbu.ml@gmail.com" target="_blank">kksubbu.ml@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Thursday 17 May 2018 08:07 AM, David T. Lewis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am thinking in terms of a Unix (Linux) installation as I write this, but here<br>
is how it should work:<span class=""><br>
<br>
- For a 64 bit Spur VM, the VM is invoked by /usr/bin/spur64 or /usr/local/bin/spur64.<br>
<br></span>
- There must be no name conflicts between /usr/local/bin and /usr/bin, and "spur64"<br>
above means "run the 64 bit Spur VM for a 64 bit image" regardless of whether it is<br>
in /usr/bin or /usr/local/bin or ~/bin.<br>
</blockquote>
<br>
I have a different take on this matter. bittiness is not just for the main program but also on all its plugins, dependent libraries and data files. Changing the name will also result in a cascade of changes in launch wrappers and other user scripts.<br>
<br>
Instead, what if we retain existing paths for 32-bit and just add directories like bin64 or lib64 for the new 64-bit code? This only involves changing $PATH and $LD_LIB_PATH.<br></blockquote><div><br></div><div>+1.  That's my instinct too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Regards .. Subbu<br>
</blockquote></div><br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>