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

[tim Rowledge]

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

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 ?
b) why does it try to load libasound at all?

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

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
You can't make a program without broken egos.