[Vm-dev] why would a unix vm try to load libasound when the commando line is either squeak -help or squeak -vm-sound-null?

David T. Lewis lewis at mail.msen.com
Tue Sep 28 02:42:07 UTC 2021

For the Unix VM, Ian designed a system of loadable VM modules. These
are analogous to the VM plugins (FilePlugin et al) except that they
are loaded directly by the VM executable itself before the image is
loaded. These modules are used to provide support for subsystems
such as sound and display.

This approach allows a single VM executable to load one of possibly
several VM modules to provide sound or display support. You can
run "squeak -help" to see the available sound (or display) modules
for any given VM. For a given module type (sound, display...) the
VM will try to load one of the available modules.

Additional notes in line below:

On Mon, Sep 27, 2021 at 05:19:11PM -0700, tim Rowledge wrote:
> OK, this is weird.
> I have an x64 cog.spur vm that runs on an x64 server. I am trying to move the system to another directory (strictly, a container running on the same machine).
> Normally it is run with 
> `./bin/squeak -encoding UTF-8 -vm-sound-null -nodisplay Blah-64bit.image -doit "stuff to do" `
> Today I started moving the files and in order to check things are getting the right permissions etc (always a pain on unix) I tired a simple 
> `./bin/squeak -h`
> Which completely failed and replied 
> ./bin/squeak: error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory

Try `./bin/squeak -vm-sound-null -h` instead, see below for explanation
of why this might work.

> So I checked on the working system and that *alsO* complains about libasound but replies
> ./bin/squeak -h
> unknown option: -h
> Usage: ./bin/squeak [<option>...] [<imageName> [<argument>...]]
>        ./bin/squeak [<option>...] -- [<argument>...]
> options begin with single -, but -- prefix is silently accepted
> vm-sound-NAS tryLoading /srv/squeakbuildfactory/bin/vm-sound-NAS.so: dlopen: libaudio.so.2: cannot open shared object file: No such file or directory
> .... and then the expected help info.
> Which now makes two mysteries - 
> a) why does the *same* vm executable behave differently ?

The VM executable attempts to find and load a sound module. Ideally,
it should use the first one that works (unless you specified one
explicitly on the command line). The results will vary depending
on what runtime sound systems may be available. The load order for
sound modules is (I think) hard coded in the VM, but the basic
idea is to step through the list of available modules and load
one that works.

If loading a sound module fails with an unresolved link problem,
the failure will not be graceful and the VM will exit without
ever getting far enough to even load the image. Results will
vary, but for the error message you saw it probably indicates
a VM loadable module that was compiled with the expectation of
being able to link to libasound.so.2, but the system that the
VM was running on did not actually have the Alsa libraries
installed, so it puked on the link error and the VM exited.

> b) why does it try to load libasound at all?

Probably because the VM had a VM module for Alsa available,
and was trying to load it. The workaround is to figure out what
sound driver you actually prefer to use, and specify it on the
the command line.

> Actually, three - on a Pi 64bit OS it doesn't complain about the libasound...

This is because either:

1) The 64 bit ARM VM for Pi does not include an Alsa sound module
so it does not fail, or 

2) The Pi 64bit OS has the necessary library support installed, so
it just works.


More information about the Vm-dev mailing list