[Clam-devel] Re: scons questions

[Pau Arumi]

Hi Greg,
I'm sending copy to the list since it's a clam-devel topic.

En/na Greg Kellum ha escrit:
> Hi Pau,
> 
> As you probably remember from yesterday, I've been trying to get the OSC 
> code working inside CLAM.  Um... I've taken a look at the existing OSC 
> code, and basically, what they've done is provided a wrapper class to 
> Ross Bencina's oscpack that simply routes messages delivered by this 
> library to a named processing in a given network.  So, I think the 
> implementation is fine, but I'm not sure if oscpack has ever been 
> compiled correctly for OS-X.  I looked at the makefile, and although 
> there are some lines in there for OS-X, the library the makefile creates 
> has the wrong extension.  I talked to Ross, and he said he didn't know 
> whether the OS-X code section ever worked, and he didn't write the 
> makefile himself.  Anyway, here's the question:  I compiled a shared 
> library for oscpack and installed it in /usr/local/lib.  I'm not sure if 
> it's built correctly though.  Then, I tried to compile an example that 
> uses the OSC code, and I got the following error message:
> 
> $ scons

do scons verbose=1
and you'll see the library path "-L" options.
but chances are that /usr/local/lib is there.

> scons: Reading SConscript files ...
> Loading qt4 tool...
> scons: done reading SConscript files.
> scons: Building targets ...
> == Linking ebowSynthesizerExe
> /usr/bin/ld: warning can't open dynamic library: liboscpack.dylib 
> referenced from: /usr/local/lib/libclam_core.dylib (checking for 
> undefined symbols may be affected) (No such file or directory, errno = 2)
> /usr/bin/ld: Undefined symbols:
> SocketReceiveMultiplexer::AsynchronousBreak()       referenced from 
> libclam expected to be defined in liboscpack.dylib
> 
> Now, this library does actually exist /usr/local/lib with the correct 
> name:  liboscpack.dylib.  Do you think that scons is not looking in the 
> directory, or do you think that it is looking there but it's not finding 
> the library because the library is not built correctly?

it seems the secons. try compiling a one-liner program against
liboscpack using some public method.

good luck!
pau