Bug 455515 - olpcsound bad libraries
olpcsound bad libraries
Status: CLOSED WORKSFORME
Product: Fedora OLPC
Classification: Retired
Component: olpcsound (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Victor Lazzarini
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-15 16:23 EDT by Daniel Drake
Modified: 2011-11-29 17:55 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-29 17:55:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
disable hetro (601 bytes, patch)
2008-07-18 12:48 EDT, Daniel Drake
no flags Details | Diff

  None (edit)
Description Daniel Drake 2008-07-15 16:23:11 EDT
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 14:55:30 EDT
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 12:48:28 EDT
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 12:54:52 EDT
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 16:03:04 EDT
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 08:49:45 EDT
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 09:11:23 EDT
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 10:35:46 EDT
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 11:40:44 EDT
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 12:07:51 EDT
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 12:35:39 EDT
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 17:55:06 EST
closing old/stale bug - we now use csound and it is working.

Note You need to log in before you can comment on or make changes to this bug.