Anonymous | Login | 03-03-2021 00:05 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||||||
0003427 | [Croquet] Hedgehog | minor | always | 04-04-06 23:34 | 02-14-07 21:35 | ||||||||
Reporter | mpm | View Status | public | ||||||||||
Assigned To | mpm | ||||||||||||
Priority | normal | Resolution | fixed | ||||||||||
Status | resolved | ||||||||||||
Summary | 0003427: hack of subclassing of OpenAL initialize in OpenALUnix | ||||||||||||
Description |
for reasons that I do not understand, the usual method of getting openALLibraryName into the OpenAL>>privateInstallLibrary: method was not working the same on Linux as on Mac and WIndows. The current thoery is that there is something subtle and wonderful about the linux VM we happened to be using, so this hack of subclassing initialize for OpenALUnix makes things work for now, and we need to revisit this issue when there is a release croquet linux vm compiled for us to test against. |
||||||||||||
Additional Information | |||||||||||||
Attached Files | |||||||||||||
|
![]() |
|
(0004711 - 264 - 274 - 274 - 274 - 274 - 274) andreas 04-08-06 11:02 |
Can you describe the problem a little more than just "it doesn't work"? Does the VM crash? Does the lookup fail? Does the VM print anything? Given that the same code works just fine for OpenGL I wonder if that isn't just some random effect on a particular machine. |
(0004807 - 1048 - 1361 - 1645 - 1645 - 1645 - 1645) conrad 04-25-06 15:42 |
I had the error that the OpenAL system library could not be found, in which case starting a Croquet morph failed with backtrace: Error: Unable to find function address ... OpenALUnix(Object)>>externalCallFailed OpenALUnix(Object)>>alcOpenDevice Following on from email on the croquet devel list: https://lists.wisc.edu/read/messages?id=857047 [^] https://lists.wisc.edu/read/messages?id=863086 [^] There is an issue with finding shared library objects on Linux distributions which separate out development portions of library packages. Bert Freudenberg suggested a fix for OpenGL. A similar change for OpenAL: OpenALUnix>>openALLibraryName ^ SmalltalkImage current osVersion = 'linux' ifTrue: ['libopenal.so.0'] ifFalse: ['openal'] allows the correct OpenAL shared library object to be found in the common situation that the runtime library (libopenal.so.0) is installed, but the development library (libopenal.so) is not. With this change, it is no longer necessary to override OpenAL>>initialize in OpenALUnix. |
(0009791 - 31 - 31 - 31 - 31 - 31 - 31) mpm 02-14-07 21:34 |
resolved with OpenAL-mpm.49.mcz |
(0009792 - 17 - 17 - 17 - 17 - 17 - 17) mpm 02-14-07 21:35 |
OpenAL-mpm.49.mcz |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
48 total queries executed. 37 unique queries executed. |