why would a unix vm try to load libasound when the commando line is either squeak -help or squeak -vm-sound-null?
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@rowledge.org; http://www.rowledge.org/tim You can't make a program without broken egos.
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.
Dave
On 2021-09-27, at 7:42 PM, David T. Lewis lewis@mail.msen.com wrote:
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.
Exactly - which was one of the reasons I got puzzled by the apparent insistence on loading libasound...
Try `./bin/squeak -vm-sound-null -h` instead, see below for explanation of why this might work.
It's making no difference at all; I've even tried ./bin/squeak -vm-sound-oss -help to see if it makes any difference. It gets a bit weirder though. One the 'old' machine where things work decently
`./bin/squeak -vm-sound-oss -help 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
ALSA <option>s:` etc etc
On the 'new ' set up ` ./bin/squeak -vm-sound-oss -help ./bin/squeak: error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory' ie as before.
It's as if sometihng in whatever config/make environment created this particular VM had some clause explicitly linking to libasound. But even that doesn't provide any reason why one side complains about libasound and then runs anyway, whilst the other complains and dies!
I guess I'll try a new VM etc tomorrow, see if that makes any difference. Whodathunk simply moving a file could cause so much bother?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FLR: Flash Lights Randomly
Hi,
Try
ldd ./bin/squeak
which will show you the libraries that the squeak binary must resolve before it even begins to start, ie, before main() is called.
In my case on x86-64
ldd squeak
linux-vdso.so.1 (0x00007ffddf20a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc93fdb1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc93fc62000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc93fc5c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc93fa6a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc940049000)
and on Arm32 PI
ldd local/squeak/squeak
linux-vdso.so.1 (0xbefce000)
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6f12000)
libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0xb6ee4000)
libutil.so.1 => /lib/arm-linux-gnueabihf/libutil.so.1 (0xb6ed1000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6ea7000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6e25000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6e12000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6cc4000)
/lib/ld-linux-armhf.so.3 (0xb6f27000)
And on Arm64
ldd local/squeak/squeak
linux-vdso.so.1 (0x0000007f86108000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f85e4b000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f85d92000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007f85d7b000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f85d66000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f85c0d000)
/lib/ld-linux-aarch64.so.1 (0x0000007f860dc000)
These libraries have to be there to get started.
To minimize the length of this email I'll send a second one about debugging this.
cheers
bruce
On 2021-09-28T05:39:24.000+02:00, tim Rowledge tim@rowledge.org wrote:
On 2021-09-27, at 7:42 PM, David T. Lewis lewis@mail.msen.com wrote: 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.
Exactly - which was one of the reasons I got puzzled by the apparent insistence on loading libasound...
Try `./bin/squeak -vm-sound-null -h` instead, see below for explanation of why this might work.
It's making no difference at all; I've even tried ./bin/squeak -vm-sound-oss -help to see if it makes any difference. It gets a bit weirder though. One the 'old' machine where things work decently `./bin/squeak -vm-sound-oss -help 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 ALSA <option>s:` etc etc On the 'new ' set up ` ./bin/squeak -vm-sound-oss -help ./bin/squeak: error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory' ie as before. It's as if sometihng in whatever config/make environment created this particular VM had some clause explicitly linking to libasound. But even that doesn't provide any reason why one side complains about libasound and then runs anyway, whilst the other complains and dies! I guess I'll try a new VM etc tomorrow, see if that makes any difference. Whodathunk simply moving a file could cause so much bother? tim -- tim Rowledge; tim@rowledge.org; www.rowledge.org/tim [http://www.rowledge.org/tim] Strange OpCodes: FLR: Flash Lights Randomly
On 2021-09-27, at 11:07 PM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Try
ldd ./bin/squeak
Woah! linux-vdso.so.1 (0x00007ffdf93d8000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fdd16a25000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdd16a1f000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fdd16a1a000) libpulse-simple.so.0 => /lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007fdd16a13000) libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007fdd16918000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdd167c7000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdd167a4000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd165b2000) /lib64/ld-linux-x86-64.so.2 (0x00007fdd16a48000) libpulse.so.0 => /lib/x86_64-linux-gnu/libpulse.so.0 (0x00007fdd1655d000) libpulsecommon-13.99.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so (0x00007fdd164db000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fdd16488000) libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fdd1645e000) libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fdd163af000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fdd163a3000) libsndfile.so.1 => /lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007fdd16325000) libasyncns.so.0 => /lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007fdd1611f000) libapparmor.so.1 => /lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007fdd16108000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdd160fd000) libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007fdd160f7000) libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fdd160ef000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fdd160c6000) liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fdd160a5000) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fdd15f85000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fdd15f68000) libFLAC.so.8 => /lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007fdd15f2a000) libogg.so.0 => /lib/x86_64-linux-gnu/libogg.so.0 (0x00007fdd15f1d000) libvorbis.so.0 => /lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007fdd15eef000) libvorbisenc.so.2 => /lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007fdd15e44000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fdd15e26000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fdd15e0c000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fdd15de9000)
That's quite a lot. I don't even remember where the vm came from - did I build it myself? No idea. It's the same version I have on my local x64 ubuntubox and that I used to make the squeaksource setup for work.
I also ran your LDD_DEBUG things and, yeah, much output. It actually tries loading libpulse-simple before libasound.
My ARM64 vm pretty much agrees with your ARM32 output, so that's a good thing.
Ho hum, more detective work.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- RIGOR MORRIS - The cat is dead
Ho hum, more detective work.
Well, it wasn't my fault, apparently. The linux x64 packages on squeak.org that use the 5.3 VM - which appears to be every one from the 5.3 release package up to the latest on in files (http://files.squeak.org/6.0alpha/Squeak6.0alpha-20582-64bit/Squeak6.0alpha-2...) have this long list of ldd output.
I have a copy of the 202101260417 package (which I accidentally spotted in the not at all easy to spot releases page of the github site) and that does not have the issue. Thus I must guess that some make related problem had crept into the system and subsequently got solved.
The two versions can be retrieved and checked from https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202101260417 and https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202003021730 ... should any one be interested in the palaeontology of it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim No single raindrop believes it is to blame for the flood
Ok, the next step to debug would be setting LD_DEBUG to see what is being loaded. I link libs is what you want but there is always 'all' if you need more scrolling practice.
I cut off output but you can see that we load the initial libraries, main() gets called and squeak starts to display messages (like -h is an unknown option) and then squeak starts trying to find libraries.
I did not have DISPLAY set so that init fails as one would expect.
Maybe this can help you see why and where your libasound falls over.
cheers
bruce
$ LD_DEBUG=libs ./local/squeak/squeak --h
12394: find library=libuuid.so.1 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/libuuid.so.1
12394:
12394: find library=libutil.so.1 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/libutil.so.1
12394:
12394: find library=libpthread.so.0 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/libpthread.so.0
12394:
12394: find library=libm.so.6 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/libm.so.6
12394:
12394: find library=libdl.so.2 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/libdl.so.2
12394:
12394: find library=libc.so.6 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/libc.so.6
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/libpthread.so.0
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/libc.so.6
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/libdl.so.2
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/libm.so.6
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/libutil.so.1
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/libuuid.so.1
12394:
12394:
12394: calling init: /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so
12394:
12394:
12394: initialize program: ./local/squeak/squeak
12394:
12394: find library=libv4l2.so.0 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/libv4l2.so.0
12394:
12394: find library=libv4lconvert.so.0 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/libv4lconvert.so.0
12394:
12394: find library=librt.so.1 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/librt.so.1
12394:
12394: find library=libjpeg.so.62 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: trying file=/lib/arm-linux-gnueabihf/libjpeg.so.62
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/libjpeg.so.62
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/librt.so.1
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/libv4lconvert.so.0
12394:
12394:
12394: calling init: /lib/arm-linux-gnueabihf/libv4l2.so.0
12394:
12394:
12394: transferring control: ./local/squeak/squeak
12394:
unknown option: --h
Usage: ./local/squeak/squeak [<option>...] [<imageName> [<argument>...]]
./local/squeak/squeak [<option>...] -- [<argument>...]
options begin with single -, but -- prefix is silently accepted
12394: ./local/squeak/squeak: error: symbol lookup error: undefined symbol: display_X11 (fatal)
12394: find library=vm-display-X11 [0]; searching
12394: search cache=/etc/ld.so.cache
12394: search path=/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp:/lib/arm-linux-gnueabihf/tls/v7l/neon:/lib/arm-linux-gnueabihf/tls/v7l/vfp:/lib/arm-linux-gnueabihf/tls/v7l:/lib/arm-linux-gnueabihf/tls/neon/vfp:/lib/arm-linux-gnueabihf/tls/neon:/lib/arm-linux-gnueabihf/tls/vfp:/lib/arm-linux-gnueabihf/tls:/lib/arm-linux-gnueabihf/v7l/neon/vfp:/lib/arm-linux-gnueabihf/v7l/neon:/lib/arm-linux-gnueabihf/v7l/vfp:/lib/arm-linux-gnueabihf/v7l:/lib/arm-linux-gnueabihf/neon/vfp:/lib/arm-linux-gnueabihf/neon:/lib/arm-linux-gnueabihf/vfp:/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp:/usr/lib/arm-linux-gnueabihf/tls/v7l/neon:/usr/lib/arm-linux-gnueabihf/tls/v7l/vfp:/usr/lib/arm-linux-gnueabihf/tls/v7l:/usr/lib/arm-linux-gnueabihf/tls/neon/vfp:/usr/lib/arm-linux-gnueabihf/tls/neon:/usr/lib/arm-linux-gnueabihf/tls/vfp:/usr/lib/arm-linux-gnueabihf/tls:/usr/lib/arm-linux-gnueabihf/v7l/neon/vfp:/usr/lib/arm-linux-gnueabihf/v7l/neon:/usr/lib/arm-linux-gnueabihf/v7l/vfp:/usr/lib/arm-linux-gnueabihf/v7l:/usr/lib/arm-linux-gnueabihf/neon/vfp:/usr/lib/arm-linux-gnueabihf/neon:/usr/lib/arm-linux-gnueabihf/vfp:/usr/lib/arm-linux-gnueabihf:/lib/tls/v7l/neon/vfp:/lib/tls/v7l/neon:/lib/tls/v7l/vfp:/lib/tls/v7l:/lib/tls/neon/vfp:/lib/tls/neon:/lib/tls/vfp:/lib/tls:/lib/v7l/neon/vfp:/lib/v7l/neon:/lib/v7l/vfp:/lib/v7l:/lib/neon/vfp:/lib/neon:/lib/vfp:/lib:/usr/lib/tls/v7l/neon/vfp:/usr/lib/tls/v7l/neon:/usr/lib/tls/v7l/vfp:/usr/lib/tls/v7l:/usr/lib/tls/neon/vfp:/usr/lib/tls/neon:/usr/lib/tls/vfp:/usr/lib/tls:/usr/lib/v7l/neon/vfp:/usr/lib/v7l/neon:/usr/lib/v7l/vfp:/usr/lib/v7l:/usr/lib/neon/vfp:/usr/lib/neon:/usr/lib/vfp:/usr/lib (system search path)
12394: trying file=/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp/vm-display-X11
12394: trying file=/lib/arm-linux-gnueabihf/tls/v7l/neon/vm-display-X11
12394: trying file=/lib/arm-linux-gnueabihf/tls/v7l/vfp/vm-display-X11
12394: trying file=/lib/arm-linux-gnueabihf/tls/v7l/vm-display-X11
12394: trying file=/lib/arm-linux-gnueabihf/tls/neon/vfp/vm-display-X11
12394: trying file=/lib/arm-linux-gnueabihf/tls/neon/vm-display-X11
12394: trying file=/lib/arm-linux-gnueabihf/tls/vfp/vm-display-X11
12394: trying file=/lib/arm-linux-gnueabihf/tls/vm-display-X11
On 2021-09-28T05:39:24.000+02:00, tim Rowledge tim@rowledge.org wrote:
On 2021-09-27, at 7:42 PM, David T. Lewis lewis@mail.msen.com wrote: 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.
Exactly - which was one of the reasons I got puzzled by the apparent insistence on loading libasound...
Try `./bin/squeak -vm-sound-null -h` instead, see below for explanation of why this might work.
It's making no difference at all; I've even tried ./bin/squeak -vm-sound-oss -help to see if it makes any difference. It gets a bit weirder though. One the 'old' machine where things work decently `./bin/squeak -vm-sound-oss -help 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 ALSA <option>s:` etc etc On the 'new ' set up ` ./bin/squeak -vm-sound-oss -help ./bin/squeak: error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory' ie as before. It's as if sometihng in whatever config/make environment created this particular VM had some clause explicitly linking to libasound. But even that doesn't provide any reason why one side complains about libasound and then runs anyway, whilst the other complains and dies! I guess I'll try a new VM etc tomorrow, see if that makes any difference. Whodathunk simply moving a file could cause so much bother? tim -- tim Rowledge; tim@rowledge.org; www.rowledge.org/tim [http://www.rowledge.org/tim] Strange OpCodes: FLR: Flash Lights Randomly
vm-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
David T. Lewis -
tim Rowledge