<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 13, 2016 at 3:34 AM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm saying that the traditional way of installing a global VM, by installing under /usr/local, cannot support dual 32 and 64-bit installation because the directory name under "lib" is exactly the same for both platforms.<br><br>Installing from cog_linux32x86_squeak.cog.<wbr>spur_201608171728.tar.gz:<br><br>   /./products/cogspurlinuxht/<span style="background-color:rgb(234,153,153)">li<wbr>b/squeak/5.0-201608171728/<wbr>squeak</span>  "32-bit"<br><br>and from cog_linux64x64_squeak.cog.<wbr>spur_201608171728.tar.gz:<br><br>  /./products/cogspur64linuxht/<span style="background-color:rgb(234,153,153)">l<wbr>ib/squeak/5.0-201608171728/<wbr>squeak</span>  "64-bit!"<br><br>copying from the highlighted, down, to the traditional /usr/local location makes that conflict.<div><div><br>I want to run the same version of each VM, so there will be no question if disparity's arise during testing.  I'd like to have access to a global "spur" (32-bit) and "spur64" commands.  Any advice for this Linux user is appreciated, thx..</div></div></div></blockquote><div><br></div><div>But since gong forward there is likely more 64-bit installs than 32 bit, perhaps that should be spur32 & spur (64-bit)?</div><div>cheers -ben</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 12, 2016 at 12:55 PM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Do you mean that you want to make a single executable to run both 32-bit and 64-bit images?<br>
If so, you can make a script which reads the image version from the header and runs it with the corresponding VM.<br>
But I don't see why you would want to do that. :)<span class="m_-4034271036986164548HOEnZb"><font color="#888888"><br>
<br>
Levente</font></span><div class="m_-4034271036986164548HOEnZb"><div class="m_-4034271036986164548h5"><br>
<br>
On Mon, 12 Dec 2016, Chris Muller wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm ready to make a push to migrate all my stuff to 64-bit, so this<br>
means I need the ability to run either a 32-bit VM or a 64-bit VM, at<br>
least for now.  Unfortunately, it appears each uses the same the VM<br>
file directory structure, and so whichever one is installed last<br>
stomps out the other.<br>
<br>
Eliot, you have unique names for VM versions, have you considered<br>
inserting something to uniquefy the names to support co-existence of<br>
32 and 64-bit of the same VM version?  Or, does anyone have any best<br>
practices to allow the co-existence of 32-bit with 64-bit VM?<br>
<br>
I'm not talking about the problem with the names of the executables<br>
(scripts) all being "squeak".  I've already been renaming the shell<br>
scripts from "squeak" to "cog" or "spur".  Now the problem between 32<br>
and 64-bit is the "lib" directory they refer to -- they share the<br>
exact same name.<br>
<br>
I still have a lot of 32-bit images around.  Does anyone have any<br>
pointers on how best to manage both a 32-bit and 64-bit?<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>
</div></div><br><br>
<br></blockquote></div><br></div></div>