Chuckk Hubbard wrote:
> On 9/8/07, *Ken Restivo* <ken@restivo.org <mailto:ken@restivo.org>>
> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, Sep 08, 2007 at 06:48:52PM -0400, Chuckk Hubbard wrote:
> > Hi. I acquired a p5 glove, and the Pd interface I found for it
> relies on
> > OSCx. I've been trying to build it, having added -fPIC to it,
> but I get
> > this:
> > make[1]: Entering directory
> `/home/chuckk/Glove/pd/externals/OSCx/src'
> > cc -Wl,-export_dynamic -shared -o sendOSC.pd_linux sendOSC.o
> htmsocket.o
> > OSC-system-dependent.o -L../../../pd/bin -lpd -lc -lm
> ../libOSC/libOSC.a
> > /usr/bin/ld: cannot find -lpd
> > collect2: ld returned 1 exit status
> > make[1]: *** [sendOSC.pd_linux] Error 1
> > make[1]: Leaving directory
> `/home/chuckk/Glove/pd/externals/OSCx/src'
> > make: *** [all] Error 2
> >
> >
> > I added several paths to the INCLUDES line in src/Makefile, as
> the guy
> > suggested, with the path to a Pd src folder, but still it can't
> find this
> > -lpd. I read man ld and tried searching for any kind of
> *libpd*, * pd.a*, or
> > *pd.so* on my entire hard drive, and none of them exist. Should
> I replace
> > this -lpd with something else? I tried removing it, and it
> built a faulty
> > set of OSCx objects that don't work.
> >
>
> The linker uses -L not -I to determine its paths.
>
> Try -L/usr/wherever/pd/libs/are/located ?
>
>
> Hi Ken, thanks for the suggestion. It doesn't seem to make a
> difference. There are a series of -L flags and a series of -I flags,
> so I'm guessing whoever wrote it knew the difference. But I tried both.
> I also tried removing the -lpd flag, since, again, there is no file on
> my system that would satisfy it, and it built dumpOSC.pd_linux,
> sendOSC.pd_linux, and OSCroute.pd_linux, but Pd cannot create a
> dumpOSC object, while it does create the other two...
So it _can_ build sendOSC.pd_linux when you remove the -lpd flag? That
makes sense because there is no need for the pd library if you're
building a dynamic shared library.
The dumpOSC problem may relate to it's use of type-punning that assumes
32 bit floats and ints. I changed unpackOSC to use an int/float union
instead.
See
http://sourceforge.net/tracker/index.php?func=detail&aid=1788587&group_id=55736&atid=478070
Actually, it built okay; I was just trying to add a dumpOSC object with no argument. With an argument it works...
-Chuckk