[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:12:33 UTC 2021
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 at rowledge.org>
wrote:
>> 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/61fd1397/attachment.html>
More information about the Vm-dev
mailing list