|Summary:||olpcsound bad libraries|
|Product:||[Retired] Fedora OLPC||Reporter:||Daniel Drake <dsd>|
|Component:||olpcsound||Assignee:||Victor Lazzarini <victor.lazzarini>|
|Status:||CLOSED WORKSFORME||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-11-29 22:55:06 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Daniel Drake 2008-07-15 20:23:11 UTC
On joyride-2163, launching TamTamMini shows: WARNING: couldn't open library '/usr/lib/csound/plugin/libstdutil.so' (/usr/lib/csound/plugins/libstdutil.so: undefined symbol: hetro_init_) WARNING: couldn't open library '/usr/lib/csound/plugin/liboggplay.so' (libogg.so: cannot open shared object file: No such file or directory) On update1, _hetro_init_ was in the .text section of that file, and liboggplay was linked against libogg.so.0 (not libogg.so) I think this is causing breakage for TamTam.
Comment 1 Daniel Drake 2008-07-17 18:55:30 UTC
I think some instruments are missing too. Certain sounds in TamTam do not work, such as the "laugh" sound. TamTam prints this message: insert_score_event(): invalid instrument number or name If I rebuild the csound we shipped in Fedora7 on Fedora 9 then the "invalid instrument" and the "WARNING: couldn't open library" messages go away.
Comment 2 Daniel Drake 2008-07-18 16:48:28 UTC
Created attachment 312153 [details] disable hetro This patch solves the hetro_init warning - hetro is excluded from OLPC builds
Comment 3 Daniel Drake 2008-07-18 16:54:52 UTC
The reason for the bad libogg link is because the build does this: gcc -o libogg.so -Wl,-Bdynamic -shared Opcodes/ogg.os -L. -L. -L/usr/local/lib -L. -L. -L/usr/lib/fltk-1.1 -lsndfile -lasound -llo -lsndfile -lvorbisfile gcc -o liboggplay.so -Wl,-Bdynamic -lvorbisfile -lvorbis -logg -shared Opcodes/oggplay.os -L. -L. -L/usr/local/lib -L. -L. -L/usr/lib/fltk-1.1 -lsndfile -lasound -llo -lsndfile -lpng -lz i.e. it creates a file called libogg.so in the current directory, then creates a library called liboggplay.so and compiles with "-L. -logg", causing it to link against the csound libogg plugin rather than /usr/lib/libogg.so.0 I'm not sure how to best attack this given my very limited knowledge of SCons
Comment 4 Victor Lazzarini 2008-07-19 20:03:04 UTC
I'll look into fixing these ASAP. Are they fedora-9 only or they are happening on fedora-7/XO as well? The insert_score_event problem might be a bug on 5.08, in the API call csoundScoreEvent(), I had another, unrelated, report of this. I'll check.
Comment 5 Daniel Drake 2008-07-21 12:49:45 UTC
They are Fedora 9 only - we are using csound-5.07 in F7 and we aren't developing that branch any more. (Perhaps the same bugs would occur if we backported olpcsound-5.08 to F7, but that's not going to happen)
Comment 6 Victor Lazzarini 2008-07-21 13:11:23 UTC
They are not on F7 as I have built and ran the installation there. I'll work on this and see where I get.
Comment 7 Victor Lazzarini 2008-07-23 14:35:46 UTC
I checked out the insert_score_event(): invalid instrument number or name problem and diagnosed it. This is caused by using a doubles version of Csound5 library mixed with a single-precision executable/host (or the other way round). The score event array gets passed as float (or double) and the csound lib expects it as double (or float). I will later look why this has arisen in the olpcsound package at all (it should not have). Would it be possible that you had two versions of _csnd.so (the binary csnd Python module) in your system?
Comment 8 Daniel Drake 2008-07-23 15:40:44 UTC
There is just one _csnd.so on the system (freshly reflashed) at /usr/lib/python2.5/site-packages/_csnd.so Is single vs double precision a case of 32 vs 64 bit, or does the precision vary on 32 bit systems alone? I am wondering whether TamTam's _aclient.so module (which interacts with csound) has been compiled with double precision (how can I check?) Thanks!
Comment 9 Victor Lazzarini 2008-07-23 16:07:51 UTC
The precision is set by an scons option (useDouble, setting -DUSE_DOUBLE) and affects how floating-point data is represented inside Csound. This is independent of the OS. But in the case of csound and OLPC, I think all packages have always been built single-precision. If you look at Koji's build logs, you will see whether this is the case, because scons reports it. As far as _aclient.so is concerned, I suppose you need to ask who packaged it.
Comment 10 Daniel Drake 2008-07-23 16:35:39 UTC
koji build logs say: CONFIGURATION DECISION: Using single-precision floating point for audio samples. /usr/lib/python2.5/site-packages/_csnd.so is unrelated to this problem because TamTam's aclient.so uses libcsound directly. TamTam is usable (except for the instruments that exhibit this bug) even when I have deleted this file. I was the last person who compiled aclient.so, with these flags: g++ -I/usr/include/python2.5 -Wall -fPIC -O2 -finline -shared -o aclient.so aclient.cpp -lasound -lcsound -lpython2.5 ...but I do not think the problem is in aclient, because if I remove olpcsound-5.08 and install csound-5.07 then the instruments start working with the very same aclient.so
Comment 11 Daniel Drake 2011-11-29 22:55:06 UTC
closing old/stale bug - we now use csound and it is working.