On Linux Mint Sylvia, I could not play sounds (e.g. ``SampledSound beep``). This occurred in the newest SWA VM build of Squeak.
Underlying problem seems to be that the Linux sound libraries for PulseAudio are not linked correctly.
(Maybe this is the same as #118)
With @krono I found this workaround: `` LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.0 LD_LIBRARY_PATH=/home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412:/lib/x86_64-linux-gnu:/lib:/usr/lib/x86_64-linux-gnu:/usr/lib: /home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412/squeak -vm-sound-pulse /home/user/Dokumente/SWA2018.app/Contents/Resources/SWA2018.image ``
Hi Eva,
On Fri, Jan 25, 2019 at 4:53 AM Eva notifications@github.com wrote:
On Linux Mint Sylvia, I could not play sounds (e.g. SampledSound beep). This occurred in the newest SWA VM build of Squeak.
Underlying problem seems to be that the Linux sound libraries for PulseAudio are not linked correctly.
(Maybe this is the same as #118 https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/118)
It might be well worth adding your message to that issue. Capturing these issues has to be a high priority.
With @krono https://github.com/krono I found this workaround: LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.0 LD_LIBRARY_PATH=/home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412:/lib/x86_64-linux-gnu:/lib:/usr/lib/x86_64-linux-gnu:/usr/lib: /home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412/squeak -vm-sound-pulse /home/user/Dokumente/SWA2018.app/Contents/Resources/SWA2018.image
Ugh, that's ugly :-). But well found you two; thanks!! The questions I have are a) where should we document this workaround to communicate it to Linux users who may be suffering from the ease problem? b) what does the LD_PRELOAD variable cause to happen, and how many linux systems is it supported on? c) is there any way we can (safely) add this to the vm startup script, or to the sound-pulse module itself, e.g. somewhere in platforms/unix/vm-sound-pulse/sqUnixSoundPulseAudio.c? or in the code that loads the module?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/360, or mute the thread https://github.com/notifications/unsubscribe-auth/APHa0PvjMt1ODGW3wJNLxErdkybE72bHks5vGv5bgaJpZM4aS083 .
Hi.
The problem here is that the sound pluing (`vm-sound-pulse`) is in fact not linked agains the `libpulse-simple.so`. So says `ldd` and a quick glance a the code does not tell me why tho.
When the sound system is initialized, it apparently tries to dynload the `vm-sound-pulse` but since it has unresolved symbols, that fails.
However, using `LD_PRELOAD`, we force the `libpulse-simple.so` into the starting process, so that the dynload can actually succeed, as the missing symbols can already be found in the process. (`LD_PRELOAD` is present on al ELF-based systems, ie, Linux/BSD, Mach-O based use `DYLD_INSERT_LIBRARIES`, ie macOS).
The proper fix would be to ling `vm-sound-pulse` with `-lpulse-simple` somehow, but looking at the Make-includes/cmake files, I wonder why that's not the case in the first place.
On Fri, Jan 25, 2019 at 1:31 PM Tobias Pape notifications@github.com wrote:
Hi.
The problem here is that the sound pluing (vm-sound-pulse) is in fact not linked agains the libpulse-simple.so. So says ldd and a quick glance a the code does not tell me why tho.
When the sound system is initialized, it apparently tries to dynload the vm-sound-pulse but since it has unresolved symbols, that fails.
However, using LD_PRELOAD, we force the libpulse-simple.so into the starting process, so that the dynload can actually succeed, as the missing symbols can already be found in the process. (LD_PRELOAD is present on al ELF-based systems, ie, Linux/BSD, Mach-O based use DYLD_INSERT_LIBRARIES, ie macOS).
The proper fix would be to ling vm-sound-pulse with -lpulse-simple somehow, but looking at the Make-includes/cmake files, I wonder why that's not the case in the first place.
I suspect the autoconfig step being run on a build machine without lib pulse correctly installed. Again that's an advantage of static makefiles; if prerequisites are unavailable the build will fail instead of the system silently (or at least very muffled) deciding not to link against a missing library.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/360#issuecomment-457736311, or mute the thread https://github.com/notifications/unsubscribe-auth/APHa0CPjFTfSsosBXq1-5TQ1FsKYXteLks5vG3edgaJpZM4aS083 .
On 2019-01-25, at 1:51 PM, Eliot Miranda notifications@github.com wrote:
I suspect the autoconfig step being run on a build machine without lib pulse correctly installed. Again that's an advantage of static makefiles; if prerequisites are unavailable the build will fail instead of the system silently (or at least very muffled) deciding not to link against a missing library.
+lots. Far better for a build to fail than a running system. Especially on a spaceship...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 9) "A TRUE Klingon warrior does not comment his code!"
That's besides the point here.
The plugin would not have been built if the library was not present. That's what the configure step is for. The VM is origrinally from a travis and I made sure the lib is there: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/scripts/ci/travis... (thats the dev lib that depends on the real one: https://packages.ubuntu.com/xenial/libpulse-dev)
All of the respecitve sound plugins are optional, and absence is expected.
Hi Tobias,
On Fri, Jan 25, 2019 at 2:27 PM Tobias Pape notifications@github.com wrote:
That's besides the point here.
The plugin would not have been built if the library was not present. That's what the configure step is for. The VM is origrinally from a travis and I made sure the lib is there: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/scripts/ci/travis... (thats the dev lib that depends on the real one: https://packages.ubuntu.com/xenial/libpulse-dev)
So how come it isn't linked against libpulse-simple.so ?
All of the respecitve sound plugins are optional, and absence is expected.
Not for a build slave, surely. Shouldn't;t the build slave build all possible variants? If we're providing prebuilt VMs (for good reason) then we have to build what we support. Things like vm-display-fbdev may be something we can not support and leave to individuals to build if they want to. But vm-sound-pulse is not in that category.
_,,,^..^,,,_ best, Eliot
On 25.01.2019, at 23:32, Eliot Miranda notifications@github.com wrote:
Hi Tobias,
On Fri, Jan 25, 2019 at 2:27 PM Tobias Pape notifications@github.com wrote:
That's besides the point here.
The plugin would not have been built if the library was not present. That's what the configure step is for. The VM is origrinally from a travis and I made sure the lib is there: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/scripts/ci/travis... (thats the dev lib that depends on the real one: https://packages.ubuntu.com/xenial/libpulse-dev)
So how come it isn't linked against libpulse-simple.so ?
I have not the slightest idea and, atm, no linux at hand. We (ie, maybe, @ekrebs5 or @fniephaus) have to look wether this stems from here or https://github.com/squeak-smalltalk/squeak-app . On macOS we have rpath issues that can come out like this and might be sensitive to be moved around…
Here we see that the lib is added in configure: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L1071
And here we see that the squeak _binary_ is actually linked agains libpulse-simple:
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L3455
That is ok, since the dynloaded vm-sound-pulse can lookup in its loading process, which (being squeak being linked against libpulse-simple) should have the syms.
Accordingly we see the plugin not begin linked against the lib: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L4111
The rest is libtool chitter-chat that i cannot understand so quick…
All of the respecitve sound plugins are optional, and absence is expected.
Not for a build slave, surely. Shouldn't;t the build slave build all possible variants? If we're providing prebuilt VMs (for good reason) then we have to build what we support. Things like vm-display-fbdev may be something we can not support and leave to individuals to build if they want to. But vm-sound-pulse is not in that category.
Did not say that. all the vm-*-* plugins seem to care for optionality. and IIRC it is nigh impossible to build for some combinations to be built with the same package set (NAS + OSS or some OSS/ALSA combos, but my memory is foggy there).
In fact, I tried to make sure as many as possible plugins to be buildable on Travis: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/698661a94af388b06b9... https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/989f7e06d041c145863...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/75f59c456f79fb4f7ca... https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ca75c6bfd0903f25917... https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a82b9cfdcf2f8d5396f... https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3a8a3c4bb7033c0e19c...
Point is: yes, I really tried to make sure the build slave builds everything necessary.
-t
_,,,^..^,,,_ best, Eliot — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Sound on Linux seem to be a mess. I'm on Ubuntu 18.04 and had no sound from Squeak. I got this error in the terminal: dev/dsp: No such file or directory I installed package osspd and that seem to solve the problem. (sudo apt-get install osspd)
Best, Karl
On Sat, Jan 26, 2019 at 12:18 AM Tobias Pape notifications@github.com wrote:
On 25.01.2019, at 23:32, Eliot Miranda notifications@github.com wrote:
Hi Tobias,
On Fri, Jan 25, 2019 at 2:27 PM Tobias Pape notifications@github.com wrote:
That's besides the point here.
The plugin would not have been built if the library was not present. That's what the configure step is for. The VM is origrinally from a travis and I made sure the lib is there:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/scripts/ci/travis...
(thats the dev lib that depends on the real one: https://packages.ubuntu.com/xenial/libpulse-dev)
So how come it isn't linked against libpulse-simple.so ?
I have not the slightest idea and, atm, no linux at hand. We (ie, maybe, @ekrebs5 or @fniephaus) have to look wether this stems from here or https://github.com/squeak-smalltalk/squeak-app . On macOS we have rpath issues that can come out like this and might be sensitive to be moved around…
Here we see that the lib is added in configure: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L1071
And here we see that the squeak _binary_ is actually linked agains libpulse-simple:
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L3455
That is ok, since the dynloaded vm-sound-pulse can lookup in its loading process, which (being squeak being linked against libpulse-simple) should have the syms.
Accordingly we see the plugin not begin linked against the lib: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L4111
The rest is libtool chitter-chat that i cannot understand so quick…
All of the respecitve sound plugins are optional, and absence is
expected.
Not for a build slave, surely. Shouldn't;t the build slave build all possible variants? If we're providing prebuilt VMs (for good reason) then we have to build what we support. Things like vm-display-fbdev may be something we can not support and leave to individuals to build if they
want
to. But vm-sound-pulse is not in that category.
Did not say that. all the vm-*-* plugins seem to care for optionality. and IIRC it is nigh impossible to build for some combinations to be built with the same package set (NAS + OSS or some OSS/ALSA combos, but my memory is foggy there).
In fact, I tried to make sure as many as possible plugins to be buildable on Travis:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/698661a94af388b06b9...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/989f7e06d041c145863...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/75f59c456f79fb4f7ca...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ca75c6bfd0903f25917...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a82b9cfdcf2f8d5396f...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3a8a3c4bb7033c0e19c...
Point is: yes, I really tried to make sure the build slave builds everything necessary.
-t
_,,,^..^,,,_ best, Eliot — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/360#issuecomment-457768165, or mute the thread https://github.com/notifications/unsubscribe-auth/AhLyW3k2M4o7CI3NLORKSlN_QTCLBc5Aks5vG5DLgaJpZM4aS083 .
But if I do SoundPlayer primGetDefaultSoundPlayer the VM segfaults. It not the newest VM.
Segmentation fault Sun Jan 27 14:42:11 2019
/home/karl/Squeak5.3/bin/squeak Squeak VM version: 5.0-201810190412 Sat Oct 20 08:15:47 UTC 2018 gcc 4.8 [Production Spur 64-bit VM] Built from: CoInterpreter VMMaker.oscog-eem.2461 uuid: b3cd33f5-6309-43a1-b669-7a1805111f34 Oct 20 2018 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2464 uuid: 0b1fa0a3-a781-4fd5-b1cf-1809796ccbbf Oct 20 2018 Revision: VM: 201810190412 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Oct 18 21:12:21 2018 CommitHash: 15341b57 Plugins: 201810190412 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Build host: Linux travis-job-7e855ac8-57b9-4f6f-bf30-fd6e0ad67398 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /home/karl/Squeak5.3/bin/ [default: /home/karl/Squeak5.3/bin/]
C stack backtrace & registers: rax 0xba4a0580 rbx 0xba4a0410 rcx 0xba4a0638 rdx 0xba4a04c8 rdi 0xba4a01e8 rsi 0xba4a01e8 rbp 0xba4a0358 rsp 0xba4a06f0 r8 0xba49fc28 r9 0xba49fce0 r10 0xba49fd98 r11 0xba49fe50 r12 0xba49ff08 r13 0xba49ffc0 r14 0xba4a0078 r15 0xba4a0130 rip 0xba4a07a8 *[0x7ffdba4a07a8] /home/karl/Squeak5.3/bin/squeak[0x41b767] /home/karl/Squeak5.3/bin/squeak[0x41d1ee] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f7d0e567890] /lib/x86_64-linux-gnu/libc.so.6(+0xb16b4)[0x7f7d0e2156b4] /home/karl/Squeak5.3/bin/squeak[0x528373] /home/karl/Squeak5.3/bin/squeak[0x458e94] /home/karl/Squeak5.3/bin/squeak[0x45a4fb] /home/karl/Squeak5.3/bin/squeak(ceSendsupertonumArgs+0x289)[0x45cb59] [0x16000bb] [0x0]
Smalltalk stack dump: 0x7ffdba4affc0 M UndefinedObject>DoIt 0x1fe78e0: a(n) UndefinedObject 0x7ffdba4b0018 I Compiler>evaluateCue:ifFail: 0x1c42888: a(n) Compiler 0x7ffdba4b0070 I Compiler>evaluateCue:ifFail:logged: 0x1c42888: a(n) Compiler 0x7ffdba4b00c8 I Compiler>evaluate:in:to:environment:notifying:ifFail:logged: 0x1c42888: a(n) Compiler 0x7ffdba4bfbc8 M [] in SmalltalkEditor(TextEditor)>evaluateSelectionAndDo: 0x4e28178: a(n) SmalltalkEditor 0x7ffdba4bfc00 M BlockClosure>on:do: 0x1c42838: a(n) BlockClosure 0x7ffdba4bfc68 I SmalltalkEditor(TextEditor)>evaluateSelectionAndDo: 0x4e28178: a(n) SmalltalkEditor 0x7ffdba4bfcb0 I SmalltalkEditor(TextEditor)>printIt 0x4e28178: a(n) SmalltalkEditor 0x7ffdba4bfce0 M SmalltalkEditor(TextEditor)>printIt: 0x4e28178: a(n) SmalltalkEditor 0x7ffdba4bfd28 M SmalltalkEditor(TextEditor)>dispatchOnKeyboardEvent: 0x4e28178: a(n) SmalltalkEditor 0x7ffdba4bfd60 M SmalltalkEditor(TextEditor)>keyStroke: 0x4e28178: a(n) SmalltalkEditor 0x7ffdba4bfda0 M [] in TextMorphForEditView(TextMorph)>keyStroke: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4bfde8 M TextMorphForEditView(TextMorph)>handleInteraction:fromEvent: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4bfe28 M TextMorphForEditView>handleInteraction:fromEvent: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4bfe78 M [] in TextMorphForEditView(TextMorph)>keyStroke: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4bfea8 M StandardToolSet class>codeCompletionAround:textMorph:keyStroke: 0x23c1a20: a(n) StandardToolSet class 0x7ffdba4bfef0 M ToolSet class>codeCompletionAround:textMorph:keyStroke: 0x23ba028: a(n) ToolSet class 0x7ffdba4bff38 M TextMorphForEditView(TextMorph)>keyStroke: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4bff78 M TextMorphForEditView>keyStroke: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4bffb8 M TextMorphForEditView(Morph)>handleKeystroke: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4bfff8 M TextMorphForEditView(TextMorph)>handleKeystroke: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4c0030 M KeyboardEvent>sentTo: 0x1c3e7c8: a(n) KeyboardEvent 0x7ffdba4c0070 M TextMorphForEditView(Morph)>handleEvent: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4c00a8 M TextMorphForEditView(Morph)>handleFocusEvent: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4c00f0 M MorphicEventDispatcher>doHandlingForFocusEvent:with: 0x1c3d5b8: a(n) MorphicEventDispatcher 0x7ffdba4b1af8 M MorphicEventDispatcher>dispatchFocusEvent:with: 0x1c3d5b8: a(n) MorphicEventDispatcher 0x7ffdba4b1b38 M TextMorphForEditView(Morph)>processFocusEvent:using: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4b1b78 M TextMorphForEditView(Morph)>processFocusEvent: 0x47860d0: a(n) TextMorphForEditView 0x7ffdba4b1bc8 M [] in HandMorph>sendFocusEvent:to:clear: 0x2777490: a(n) HandMorph 0x7ffdba4b1c08 M BlockClosure>ensure: 0x1c3d4a0: a(n) BlockClosure 0x7ffdba4b1c48 M KeyboardEvent(MorphicEvent)>becomeActiveDuring: 0x1c3cce8: a(n) KeyboardEvent 0x7ffdba4b1c98 M [] in HandMorph>sendFocusEvent:to:clear: 0x2777490: a(n) HandMorph 0x7ffdba4b1cd8 M BlockClosure>ensure: 0x1c3d2d0: a(n) BlockClosure 0x7ffdba4b1d18 M HandMorph>becomeActiveDuring: 0x2777490: a(n) HandMorph 0x7ffdba4b1d68 M [] in HandMorph>sendFocusEvent:to:clear: 0x2777490: a(n) HandMorph 0x7ffdba4b1da8 M BlockClosure>ensure: 0x1c3d100: a(n) BlockClosure 0x7ffdba4b1de8 M PasteUpMorph>becomeActiveDuring: 0x24a5640: a(n) PasteUpMorph 0x7ffdba4b1e30 M HandMorph>sendFocusEvent:to:clear: 0x2777490: a(n) HandMorph 0x7ffdba4b1e88 M HandMorph>sendEvent:focus:clear: 0x2777490: a(n) HandMorph 0x7ffdba4b1ed0 M HandMorph>sendKeyboardEvent: 0x2777490: a(n) HandMorph 0x7ffdba4b1f10 M HandMorph>handleEvent: 0x2777490: a(n) HandMorph 0x7ffdba4b1f68 M HandMorph>processEvents 0x2777490: a(n) HandMorph 0x7ffdba4b1fa0 M [] in WorldState>doOneCycleNowFor: 0x269f738: a(n) WorldState 0x7ffdba4b1fe8 M Array(SequenceableCollection)>do: 0x200c708: a(n) Array 0x7ffdba4b2020 M WorldState>handsDo: 0x269f738: a(n) WorldState 0x7ffdba4b2060 M WorldState>doOneCycleNowFor: 0x269f738: a(n) WorldState 0x7ffdba4b2098 M WorldState>doOneCycleFor: 0x269f738: a(n) WorldState 0x7ffdba4b20d0 M PasteUpMorph>doOneCycle 0x24a5640: a(n) PasteUpMorph 0x7ffdba4b2100 M [] in MorphicProject>spawnNewProcess 0x28b2df8: a(n) MorphicProject 0x4e313f0 s [] in BlockClosure>newProcess
Most recent primitives at:put: at: at:put: at: at:put: at: at:put: at: at:put: at: at:put: at: at:put: at: at:put: at: at:put: at: at:put: at: at:put: at: at:put: at:put: at:put: value: value: - - - newFrom: newFrom: value at: at: buildTreeFrom:maxDepth: buildTreeFrom:maxDepth: buildTreeFrom:maxDepth: basicNew basicNew // // second second initialize initialize initialize initialize replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: size at: size at: at: at:put: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: value at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: bitLengthAt: bitLengthAt: bitLengthAt: maxCode maxCode maxCode maxCode maxCode maxCode maxCode maxCode maxCode maxCode maxCode at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: value:value: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: at: bitPosition bitPosition bitPosition on:from:to: on:from:to: at: nextBits:put: nextBits:put: nextBits:put: byteAt:put: byteAt:put: nextBytePut: bitXor: replaceFrom:to:with:startingAt: encodeLengthField: value value size size size size basicNew perform: size newMethod:header: size at: at:put: at: at:put: at: at:put: objectAt:put: objectAt:put: objectAt:put: objectAt:put: at: at:put: at: at:put: at: at:put: basicNew withArgs:executeMethod: primGetDefaultSoundPlayer
stack page bytes 8192 available headroom 5576 minimum unused headroom 6032
(Segmentation fault) Aborted (core dumped)
On Sun, Jan 27, 2019 at 2:41 PM karl ramberg karlramberg@gmail.com wrote:
Sound on Linux seem to be a mess. I'm on Ubuntu 18.04 and had no sound from Squeak. I got this error in the terminal: dev/dsp: No such file or directory I installed package osspd and that seem to solve the problem. (sudo apt-get install osspd)
Best, Karl
On Sat, Jan 26, 2019 at 12:18 AM Tobias Pape notifications@github.com wrote:
On 25.01.2019, at 23:32, Eliot Miranda notifications@github.com
wrote:
Hi Tobias,
On Fri, Jan 25, 2019 at 2:27 PM Tobias Pape notifications@github.com wrote:
That's besides the point here.
The plugin would not have been built if the library was not present. That's what the configure step is for. The VM is origrinally from a travis and I made sure the lib is there:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/scripts/ci/travis...
(thats the dev lib that depends on the real one: https://packages.ubuntu.com/xenial/libpulse-dev)
So how come it isn't linked against libpulse-simple.so ?
I have not the slightest idea and, atm, no linux at hand. We (ie, maybe, @ekrebs5 or @fniephaus) have to look wether this stems from here or https://github.com/squeak-smalltalk/squeak-app . On macOS we have rpath issues that can come out like this and might be sensitive to be moved around…
Here we see that the lib is added in configure: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L1071
And here we see that the squeak _binary_ is actually linked agains libpulse-simple:
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L3455
That is ok, since the dynloaded vm-sound-pulse can lookup in its loading process, which (being squeak being linked against libpulse-simple) should have the syms.
Accordingly we see the plugin not begin linked against the lib: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L4111
The rest is libtool chitter-chat that i cannot understand so quick…
All of the respecitve sound plugins are optional, and absence is
expected.
Not for a build slave, surely. Shouldn't;t the build slave build all possible variants? If we're providing prebuilt VMs (for good reason)
then
we have to build what we support. Things like vm-display-fbdev may be something we can not support and leave to individuals to build if they
want
to. But vm-sound-pulse is not in that category.
Did not say that. all the vm-*-* plugins seem to care for optionality. and IIRC it is nigh impossible to build for some combinations to be built with the same package set (NAS + OSS or some OSS/ALSA combos, but my memory is foggy there).
In fact, I tried to make sure as many as possible plugins to be buildable on Travis:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/698661a94af388b06b9...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/989f7e06d041c145863...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/75f59c456f79fb4f7ca...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ca75c6bfd0903f25917...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a82b9cfdcf2f8d5396f...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3a8a3c4bb7033c0e19c...
Point is: yes, I really tried to make sure the build slave builds everything necessary.
-t
_,,,^..^,,,_ best, Eliot — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/360#issuecomment-457768165, or mute the thread https://github.com/notifications/unsubscribe-auth/AhLyW3k2M4o7CI3NLORKSlN_QTCLBc5Aks5vG5DLgaJpZM4aS083 .
On 27.01.2019, at 14:41, karl ramberg karlramberg@gmail.com wrote:
Sound on Linux seem to be a mess. I'm on Ubuntu 18.04 and had no sound from Squeak. I got this error in the terminal: dev/dsp: No such file or directory I installed package osspd and that seem to solve the problem. (sudo apt-get install osspd)
This is the exact problem described.
Please try " export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.0" (or whereever that file is on your pc, and maybe i386 instead of x86_64 if you're running 32bit) and tell us if it helps in your case.
best regards -Tobias
Best, Karl
On Sat, Jan 26, 2019 at 12:18 AM Tobias Pape notifications@github.com wrote:
On 25.01.2019, at 23:32, Eliot Miranda notifications@github.com wrote:
Hi Tobias,
On Fri, Jan 25, 2019 at 2:27 PM Tobias Pape notifications@github.com wrote:
That's besides the point here.
The plugin would not have been built if the library was not present. That's what the configure step is for. The VM is origrinally from a travis and I made sure the lib is there: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/scripts/ci/travis... (thats the dev lib that depends on the real one: https://packages.ubuntu.com/xenial/libpulse-dev)
So how come it isn't linked against libpulse-simple.so ?
I have not the slightest idea and, atm, no linux at hand. We (ie, maybe, @ekrebs5 or @fniephaus) have to look wether this stems from here or https://github.com/squeak-smalltalk/squeak-app . On macOS we have rpath issues that can come out like this and might be sensitive to be moved around…
Here we see that the lib is added in configure: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L1071
And here we see that the squeak _binary_ is actually linked agains libpulse-simple:
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L3455
That is ok, since the dynloaded vm-sound-pulse can lookup in its loading process, which (being squeak being linked against libpulse-simple) should have the syms.
Accordingly we see the plugin not begin linked against the lib: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L4111
The rest is libtool chitter-chat that i cannot understand so quick…
All of the respecitve sound plugins are optional, and absence is expected.
Not for a build slave, surely. Shouldn't;t the build slave build all possible variants? If we're providing prebuilt VMs (for good reason) then we have to build what we support. Things like vm-display-fbdev may be something we can not support and leave to individuals to build if they want to. But vm-sound-pulse is not in that category.
Did not say that. all the vm-*-* plugins seem to care for optionality. and IIRC it is nigh impossible to build for some combinations to be built with the same package set (NAS + OSS or some OSS/ALSA combos, but my memory is foggy there).
In fact, I tried to make sure as many as possible plugins to be buildable on Travis: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/698661a94af388b06b9... https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/989f7e06d041c145863...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/75f59c456f79fb4f7ca... https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ca75c6bfd0903f25917... https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a82b9cfdcf2f8d5396f... https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3a8a3c4bb7033c0e19c...
Point is: yes, I really tried to make sure the build slave builds everything necessary.
-t
_,,,^..^,,,_ best, Eliot — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Hi, I can't get the LD_PRELOAD trick to function.
Best, Karl
On Sun, Jan 27, 2019 at 2:50 PM Tobias Pape Das.Linux@gmx.de wrote:
On 27.01.2019, at 14:41, karl ramberg karlramberg@gmail.com wrote:
Sound on Linux seem to be a mess. I'm on Ubuntu 18.04 and had no sound from Squeak. I got this error in the terminal: dev/dsp: No such file or directory I installed package osspd and that seem to solve the problem. (sudo apt-get install osspd)
This is the exact problem described.
Please try " export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.0" (or whereever that file is on your pc, and maybe i386 instead of x86_64 if you're running 32bit) and tell us if it helps in your case.
best regards -Tobias
Best, Karl
On Sat, Jan 26, 2019 at 12:18 AM Tobias Pape notifications@github.com
wrote:
On 25.01.2019, at 23:32, Eliot Miranda notifications@github.com
wrote:
Hi Tobias,
On Fri, Jan 25, 2019 at 2:27 PM Tobias Pape notifications@github.com wrote:
That's besides the point here.
The plugin would not have been built if the library was not present. That's what the configure step is for. The VM is origrinally from a travis and I made sure the lib is there:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/scripts/ci/travis...
(thats the dev lib that depends on the real one: https://packages.ubuntu.com/xenial/libpulse-dev)
So how come it isn't linked against libpulse-simple.so ?
I have not the slightest idea and, atm, no linux at hand. We (ie, maybe, @ekrebs5 or @fniephaus) have to look wether this stems
from here or https://github.com/squeak-smalltalk/squeak-app .
On macOS we have rpath issues that can come out like this and might be
sensitive to be moved around…
Here we see that the lib is added in configure:
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L1071
And here we see that the squeak _binary_ is actually linked agains
libpulse-simple:
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L3455
That is ok, since the dynloaded vm-sound-pulse can lookup in its loading
process, which (being squeak being linked against libpulse-simple) should have the syms.
Accordingly we see the plugin not begin linked against the lib:
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/483526374#L4111
The rest is libtool chitter-chat that i cannot understand so quick…
All of the respecitve sound plugins are optional, and absence is
expected.
Not for a build slave, surely. Shouldn't;t the build slave build all possible variants? If we're providing prebuilt VMs (for good reason)
then
we have to build what we support. Things like vm-display-fbdev may be something we can not support and leave to individuals to build if they
want
to. But vm-sound-pulse is not in that category.
Did not say that. all the vm-*-* plugins seem to care for optionality.
and IIRC it is nigh impossible to build for some combinations to be built with the same package set (NAS + OSS or some OSS/ALSA combos, but my memory is foggy there).
In fact, I tried to make sure as many as possible plugins to be
buildable on Travis:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/698661a94af388b06b9...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/989f7e06d041c145863...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/75f59c456f79fb4f7ca...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ca75c6bfd0903f25917...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a82b9cfdcf2f8d5396f...
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3a8a3c4bb7033c0e19c...
Point is: yes, I really tried to make sure the build slave builds
everything necessary.
-t
_,,,^..^,,,_ best, Eliot — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
On Sun, 27 Jan 2019, karl ramberg wrote:
I can't get the LD_PRELOAD trick to function.
You have to pass -vm-sound-pulse to the VM. The following works for me:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 ./bin/squeak -vm-sound-pulse ./shared/trunk.image
Note that the squeak.sh script will not handle the -vm-sound-pulse switch properly, so the VM is invoked directly.
Levente
Thanks, that worked.
Best, Karl
On Sun, Jan 27, 2019 at 7:08 PM Levente Uzonyi leves@caesar.elte.hu wrote:
On Sun, 27 Jan 2019, karl ramberg wrote:
I can't get the LD_PRELOAD trick to function.
You have to pass -vm-sound-pulse to the VM. The following works for me:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 ./bin/squeak -vm-sound-pulse ./shared/trunk.image
Note that the squeak.sh script will not handle the -vm-sound-pulse switch properly, so the VM is invoked directly.
Levente
I'm having the exact same problem with both the PulseAudio and the ALSA plugin on Ubuntu with the build.linux64x64 squeak.cog.spur build.
Both self compiled and the binary releases of the plugins are not linked against the appropriate libraries, even when built with all the relevant headers and libraries available.
Looking at the plugin makefiles, it seems that the problem is that the plugin Makefile defines the link libraries in the (empty!) $LIBS define while autoconf puts them in the (unused) $PLIBS define.
If I hand edit the generated makefile so that it links using the right libraries, the plugin works correctly.
See attached for the generated Makefile with the PLIBS/LIBS error. [Makefile.txt](https://github.com/OpenSmalltalk/opensmalltalk-vm/files/3667916/Makefile.txt)
I tried tracing through this to see where this error occurs, but the autoconf stuff was too complex for me.
This should hopefully be the correct fix in this case: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/452
Closed #360 via a71f6337eb1d64d72910f3908b5437d3e8bcf10a.
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Eva
-
karl ramberg -
Kirtai
-
Levente Uzonyi -
tim Rowledge -
Tobias Pape -
Tobias Pape
-
Tom Beckmann