<div>Hi,<br></div><div><br></div><div>Try<br></div><div><br></div><div>ldd ./bin/squeak<br></div><div><br></div><div>which will show you the libraries that the squeak binary must resolve before it even begins to start, ie, before main() is called.<br></div><div><br></div><div>In my case on x86-64<br></div><div><br></div><div>ldd squeak<br></div><div>linux-vdso.so.1 (0x00007ffddf20a000)<br></div><div>libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc93fdb1000)<br></div><div>libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc93fc62000)<br></div><div>libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc93fc5c000)<br></div><div>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc93fa6a000)<br></div><div>/lib64/ld-linux-x86-64.so.2 (0x00007fc940049000)<br></div><div><br></div><div><br></div><div><br></div><div>and on Arm32 PI <br></div><div><br></div><div>ldd local/squeak/squeak<br></div><div>        linux-vdso.so.1 (0xbefce000)<br></div><div>        /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6f12000)<br></div><div>        libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0xb6ee4000)<br></div><div>        libutil.so.1 => /lib/arm-linux-gnueabihf/libutil.so.1 (0xb6ed1000)<br></div><div>        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6ea7000)<br></div><div>        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6e25000)<br></div><div>        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6e12000)<br></div><div>        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6cc4000)<br></div><div>        /lib/ld-linux-armhf.so.3 (0xb6f27000)<br></div><div><br></div><div>And on Arm64<br></div><div><br></div><div>ldd local/squeak/squeak<br></div><div>        linux-vdso.so.1 (0x0000007f86108000)<br></div><div>        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f85e4b000)<br></div><div>        libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f85d92000)<br></div><div>        librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007f85d7b000)<br></div><div>        libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f85d66000)<br></div><div>        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f85c0d000)<br></div><div>        /lib/ld-linux-aarch64.so.1 (0x0000007f860dc000)<br></div><div><br></div><div>These libraries have to be there to get started.<br></div><div><br></div><div>To minimize the length of this email I'll send a second one about debugging this.<br></div><div><br></div><div>cheers<br></div><div><br></div><div>bruce<br></div><div ><br></div><div class="ik_mail_quote"><div>On 2021-09-28T05:39:24.000+02:00, tim Rowledge <tim@rowledge.org> wrote:</div><blockquote class="ws-ng-quote"><pre style="white-space: normal;"><blockquote class="ws-ng-quote">  On 2021-09-27, at 7:42 PM, David T. Lewis <<a class="defaultMailLink" href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br> <br> <br> For the Unix VM, Ian designed a system of loadable VM modules. These<br> are analogous to the VM plugins (FilePlugin et al) except that they<br> are loaded directly by the VM executable itself before the image is<br> loaded. These modules are used to provide support for subsystems<br> such as sound and display.<br></blockquote> <br>Exactly - which was one of the reasons I got puzzled by the apparent insistence on loading libasound...<br><br><blockquote class="ws-ng-quote">  <br> Try `./bin/squeak -vm-sound-null -h` instead, see below for explanation<br> of why this might work.<br></blockquote> <br>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<br><br>`./bin/squeak -vm-sound-oss -help<br>Usage: ./bin/squeak [<option>...] [<imageName> [<argument>...]]<br>       ./bin/squeak [<option>...] -- [<argument>...]<br>options begin with single -, but -- prefix is silently accepted<br>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<br><br>ALSA <option>s:` etc etc<br><br>On the 'new ' set up <br>` ./bin/squeak -vm-sound-oss -help<br>./bin/squeak: error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory'<br>ie as before.<br><br>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!<br><br>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?<br><br>tim<br>--<br>tim Rowledge; <a class="defaultMailLink" href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a class="defaultMailLink"  href="http://www.rowledge.org/tim" target="_blank">www.rowledge.org/tim</a><br>Strange OpCodes: FLR: Flash Lights Randomly</pre></blockquote></div>