[Vm-dev] why would a unix vm try to load libasound when the commando line is either squeak -help or squeak -vm-sound-null?
bruce.oneel at pckswarms.ch
Tue Sep 28 06:07:54 UTC 2021
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
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
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)
and on Arm32 PI
=> /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6f12000)
libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1
libutil.so.1 => /lib/arm-linux-gnueabihf/libutil.so.1
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6
And on Arm64
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6
These libraries have to be there to get started.
To minimize the length of this email I'll send a second one about
On 2021-09-28T05:39:24.000+02:00, tim Rowledge <tim at rowledge.org>
>> On 2021-09-27, at 7:42 PM, David T. Lewis <lewis at mail.msen.com>
>> For the Unix VM, Ian designed a system of loadable VM modules.
>> are analogous to the VM plugins (FilePlugin et al) except that
>> are loaded directly by the VM executable itself before the image
>> 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
>> 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
> 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
> tim Rowledge; tim at rowledge.org; www.rowledge.org/tim
> Strange OpCodes: FLR: Flash Lights Randomly
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev