Re: [squeak-dev] managing the transition to 64-bit

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] managing the transition to 64-bit

Eliot Miranda-2
 
Hi Chris,

On Dec 12, 2016, at 3:43 PM, Ben Coman <[hidden email]> wrote:



On Tue, Dec 13, 2016 at 3:34 AM, Chris Muller <[hidden email]> wrote:
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.

Installing from cog_linux32x86_squeak.cog.spur_201608171728.tar.gz:

   /./products/cogspurlinuxht/lib/squeak/5.0-201608171728/squeak  "32-bit"

and from cog_linux64x64_squeak.cog.spur_201608171728.tar.gz:

  /./products/cogspur64linuxht/lib/squeak/5.0-201608171728/squeak  "64-bit!"

copying from the highlighted, down, to the traditional /usr/local location makes that conflict.

I like any of the following:
    /usr/local/squeak/{lib,lib64}/squeak/5.x-20yymmddhhmm/

    /usr/local/squeak/{lib32,lib}/squeak/5.x-20yymmddhhmm/

    /usr/local/squeak/{lib32,lib64}/squeak/5.x-20yymmddhhmm/

and then have /usr/local/squeak/squeak & /usr/local/squeak/bin/squeak determine which lib dir to use based on e.g. the od program, or possibly hexdump.

Does this make sense?


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..

But since gong forward there is likely more 64-bit installs than 32 bit, perhaps that should be spur32 & spur (64-bit)?
cheers -ben

 

On Mon, Dec 12, 2016 at 12:55 PM, Levente Uzonyi <[hidden email]> wrote:
Do you mean that you want to make a single executable to run both 32-bit and 64-bit images?
If so, you can make a script which reads the image version from the header and runs it with the corresponding VM.
But I don't see why you would want to do that. :)

Levente


On Mon, 12 Dec 2016, Chris Muller wrote:

I'm ready to make a push to migrate all my stuff to 64-bit, so this
means I need the ability to run either a 32-bit VM or a 64-bit VM, at
least for now.  Unfortunately, it appears each uses the same the VM
file directory structure, and so whichever one is installed last
stomps out the other.

Eliot, you have unique names for VM versions, have you considered
inserting something to uniquefy the names to support co-existence of
32 and 64-bit of the same VM version?  Or, does anyone have any best
practices to allow the co-existence of 32-bit with 64-bit VM?

I'm not talking about the problem with the names of the executables
(scripts) all being "squeak".  I've already been renaming the shell
scripts from "squeak" to "cog" or "spur".  Now the problem between 32
and 64-bit is the "lib" directory they refer to -- they share the
exact same name.

I still have a lot of 32-bit images around.  Does anyone have any
pointers on how best to manage both a 32-bit and 64-bit?
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] managing the transition to 64-bit

David T. Lewis
 
On Mon, Dec 12, 2016 at 05:25:53PM -0800, Eliot Miranda wrote:

>  
> > On Dec 12, 2016, at 3:43 PM, Ben Coman <[hidden email]> wrote:
> >
> >> On Tue, Dec 13, 2016 at 3:34 AM, Chris Muller <[hidden email]> wrote:
> >> 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.
> >>
> >> Installing from cog_linux32x86_squeak.cog.spur_201608171728.tar.gz:
> >>
> >>    /./products/cogspurlinuxht/lib/squeak/5.0-201608171728/squeak  "32-bit"
> >>
> >> and from cog_linux64x64_squeak.cog.spur_201608171728.tar.gz:
> >>
> >>   /./products/cogspur64linuxht/lib/squeak/5.0-201608171728/squeak  "64-bit!"
> >>
> >> copying from the highlighted, down, to the traditional /usr/local location makes that conflict.
>
> I like any of the following:
>     /usr/local/squeak/{lib,lib64}/squeak/5.x-20yymmddhhmm/
>
>     /usr/local/squeak/{lib32,lib}/squeak/5.x-20yymmddhhmm/
>
>     /usr/local/squeak/{lib32,lib64}/squeak/5.x-20yymmddhhmm/
>
> and then have /usr/local/squeak/squeak & /usr/local/squeak/bin/squeak determine which lib dir to use based on e.g. the od program, or possibly hexdump.
>
> Does this make sense?

The fundamental requirement is that the run script (/usr/local/bin/[squeak|cog|spur|spur64])
needs to be able to select a folder in /usr/local/lib/squeak/ that contains something runnable.

That folder needs to be distinct by (at least) 32/64 bit host, 32/64 bit image, and Spur versus V3.

The fundamental constraint is that VM plugins cannot be mixed between those combinations, so
at the present time organizing them in distinct folders under /usr/local/lib/squeak provides
a practical solution.

Dave