[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 O'Neel bruce.oneel at pckswarms.ch
Tue Sep 28 06:07:54 UTC 2021



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

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-v7l.so (0xb6f12000)

        libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1

        libutil.so.1 => /lib/arm-linux-gnueabihf/libutil.so.1

        libpthread.so.0 =>
/lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6ea7000)

        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

        /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

        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

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



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>
>>  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 at rowledge.org; www.rowledge.org/tim
> [http://www.rowledge.org/tim]
> Strange OpCodes: FLR: Flash Lights Randomly

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210928/46527ef7/attachment-0001.html>

More information about the Vm-dev mailing list