[CLAM] Building and installing a processing object with Sconstruct and several shared objects

David García Garzón dgarcia at iua.upf.edu
Tue May 12 17:55:48 PDT 2009

I would like to help you but I think we need more information. When a program 
crashes one can get a backtrace with gdb that will help to know where it is 
crashing. Often the crash is caused by a failed assertion and you will get the 
backtrace in the console without using gdb. Sometimes weird memory access can 
make later code to crash, in those situations valgrind is of great help. Of 
course, having the code would also help us to spot typical caveats with clam 
and c++. If it crashes on plugin loading you should review the registrator 
(cxx) and other global/static initialization you could have in your classes. 
Assure that you changed all the names when copying the example. If it crashes 
when creating a processing, (plugin loading and processing creation are 
different events) then you should check construction and configuration. A 
typical error is not being aware that Configure is called more than once. 
Symbol collision could be a problem but grep tells me we didn't defined 
poly_FIR_interp. If still in doubt, namespaces can help you.

When linking a shared library, missing symbols are not reported. A trick to 
get the report is trying to build a program by linking the library as the only 
g++ libintDec.so  -o deleteme
Still, if you get missing symbols and adding them solves the problem, then we 
have a bug in clam. The library should not load but it should not cause a 


A Dimarts 12 Maig 2009 22:21:42, Mikael Andreen va escriure:
> Hello!
> I found it easy to get started with CLAM using the examples on the
> web. I have used the following Sconstruct file to build and install my
> processings for use with the Network Editor:
> http://clam-project.org/wiki/Building_a_processing_library. I however
> have a problem when I construct more complex signal processing
> programs. The problems occur when my processing class has members of
> classes that I have written myself. When I use the Sconstruct file in
> the link above to build my library, the Network editor crashes as soon
> as I try to load my plugin (although my classes stand alone are
> debugged and working) . I know very little about dynamic linking and
> SConstruct so I would be glad if someone helped me out on how to write
> a Sconstruct file that makes the linking right (if the SCons file is
> the problem). I have three different classes: a class called intDec is
> the processing object, poly_FIR_dec is a class used by the processing
> object and likewise the class poly_FIR_interp. What happens when these
> objects are shared? Can it be name-conflicts that make the processing
> crash? Some features are similiar and named the same in poly_FIR_dec
> and poly_FIR_interp for instance, is this a problem when the objects
> are shared? Any thoughts on how to solve this problem and the correct
> c++ programming practises surrounding it are welcome This is the
> output from my compile process:
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> g++ -o poly_FIR_interp.os -c -g -O3 -Wall -fPIC -DCLAM_FLOAT
> -DUSE_FFTW3=1 -I/usr/local/include -I/usr/include/alsa
> poly_FIR_interp.cxx
> g++ -o intDec.os -c -g -O3 -Wall -fPIC -DCLAM_FLOAT -DUSE_PTHREADS=1
> -I/usr/local/include -I/usr/include/alsa intDec.cxx
> g++ -o poly_FIR_dec.os -c -g -O3 -Wall -fPIC -DCLAM_FLOAT
> -DUSE_FFTW3=1 -I/usr/local/include -I/usr/include/alsa
> poly_FIR_dec.cxx
> g++ -o libintDec.so -shared poly_FIR_interp.os intDec.os
> poly_FIR_dec.os -lclam_core -lclam_audioio -lclam_processing
> scons: `install' is up to date.
> scons: done building targets.
> Best Regards, Mikael
> _______________________________________________
> CLAM mailing list
> CLAM at iua.upf.es
> http://clam.iua.upf.edu

David García Garzón
(Work) dgarcia at iua dot upf anotherdot es

More information about the clam-users mailing list