[PD-dev] libpd search paths

Fri Feb 15 18:52:23 CET 2019

Ok, I finally got the addon to compile and run correctly (tests passed !)
The answer was simple : just use the master branch of libpd.
I started tweaking the Makefile of v0.11.0 to include g_undo.c (which I 
noticed was containing the canvas_undo_undo function) in the sources but 
it was not sufficient.
So I grabbed the master branch after seeing it seemed more up-to-date, 
and voilà.
I still need to test this local version with the node project that loads 
externals, but at least I have my own working local version which I can 
modify at will.

Thanks again for the help, I'll let you know how this goes with externals.
Joseph

Le 15/02/19 à 15:11, Joseph Larralde a écrit :
> For the moment I'm using the default Makefile of libpd (version tagged 
> 0.11.0), which makes use of the -DHAVE_LIBDL flag.
> It can't find the HAVE_LIBPD definition anywhere, though ... is this 
> normal ?
> Sorry for my lack of knowledge of autotools, makefile, etc, but should 
> I add `HAVE_LIBPD =` at the beginning of the Makefile ? (e.g. after 
> `LIBPD_IMPLIB =` and `LIBPD_DEF =` lines ?)
> Or should it be added to the cflags with -DHAVE_LIBPD ?
>
> I added both and the addon builds fine (I got rid of the char * 
> related errors by adding the -fpermissive flag), but I still get stuck 
> when trying to run the js automated tests :
> they fail with an `undefined symbol` error, the undefined symbol being 
> `canvas_undo_undo`.
> Sounds familiar to anybody ?
> I have no idea how to solve this ...
>
> Thanks,
> Joseph
>
> Le 14/02/19 à 14:32, Dan Wilcox a écrit :
>> If you're building libpd via a custom Makefile, see the flags used in 
>> the libpd Makefile. Also, if you're using the libpd Makefile, 
>> double-check that HAVE_LIBPD is being defined.
>>
>> On Thu, Feb 14, 2019 at 2:30 PM Joseph Larralde 
>> <joseph.larralde at gmail.com <mailto:joseph.larralde at gmail.com>> wrote:
>>
>>     Thank you Dan for your explanation.
>>     And thanks everyone for helping.
>>
>>     Yesterday I tried to recompile the node addon to use it locally
>>     but got into other trouble.
>>     I first recompiled libpd with MULTI=false after Christof's
>>     suggestion (to enable the PDINSTANCE flag) but node-gyp was the
>>     first wall I was still hitting.
>>     It seems there are still some slight updates I need to do in the
>>     addon's code (I got some char * vs const char * error).
>>     Your 3rd point makes obvious sense and I'll try this in the first
>>     place today.
>>
>>     Joseph
>>
>>     Le 14/02/19 à 13:07, Dan Wilcox a écrit :
>>>     A few things:
>>>
>>>     1. libpd does not use any paths, settings, audio/midi backends,
>>>     etc from desktop pd. It is only the core and less than "pd
>>>     without the gui." This is by design as it makes no assumptions
>>>     about the environment since it can be running in all manner of
>>>     places. This means it will only search paths relative to an
>>>     opened patch and those added explicitly by
>>>     llibpd_add_to_search_path().
>>>
>>>     2. Loading an external, whether it was compiled against 0.47 or
>>>     0.49 should work as, largely, the pd API has not changed that much.
>>>
>>>     3. libpd needs to be built with -DHAVE_LIBDL in order to be able
>>>     to load separate, precompiled externals.
>>>
>>>     4. Some environments do *not* allow loading dynamic libraries
>>>     for legal/security reasons, ie. iOS. I don't this is the
>>>     problem, but it's good to know...
>>>
>>>     I image you're issue is more to do with 3.
>>>
>>>         Message: 1
>>>         Date: Wed, 13 Feb 2019 15:04:19 +0100
>>>         From: Joseph Larralde <joseph.larralde at gmail.com
>>>         <mailto:joseph.larralde at gmail.com>>
>>>         To: Giulio Moro <giuliomoro at yahoo.it
>>>         <mailto:giuliomoro at yahoo.it>>, Lucas Cordiviola
>>>                 <lucarda27 at hotmail.com
>>>         <mailto:lucarda27 at hotmail.com>>, pd-dev <pd-dev at lists.iem.at
>>>         <mailto:pd-dev at lists.iem.at>>
>>>         Subject: Re: [PD-dev] libpd search paths
>>>         Message-ID: <2354c1c4-e6db-9143-1402-76dcd37b43a8 at gmail.com
>>>         <mailto:2354c1c4-e6db-9143-1402-76dcd37b43a8 at gmail.com>>
>>>         Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>
>>>         Mmmh you might have found the clue ...
>>>         Actually I built the externals against pd version 0.49-0 and
>>>         it makes
>>>         sense that they load properly with the same version.
>>>         node-libpd comes with an arm libpd binary which seems to
>>>         come from an
>>>         older version of pd (added 1 year ago).
>>>         I can already tell that it's not an architecture issue because
>>>         everything is working on my pi : the addon is loading and
>>>         running
>>>         abstractions when used in a node program, and pd is loading
>>>         and running
>>>         my externals.
>>>         Only loading my externals from node-libpd doesn't work.
>>>         Still trying to get a local version of node-libpd to work
>>>         ... then I'll
>>>         replace the libpd.so with one that I'll build from the
>>>         latest version.
>>>         I can't see another explanation.
>>>         Do you know something about incompatibilities between
>>>         different versions
>>>         of pd ?
>>>         The libpd.so used by the addon is probably not older than 0.47
>>>
>>>
>>>
>>>     -- 
>>>     Dan Wilcox
>>>     @danomatika
>>>     danomatika.com <http://danomatika.com>
>>>     robotcowboy.com <http://robotcowboy.com>
>>
>>
>>
>> -- 
>> Dan Wilcox
>> @danomatika
>> danomatika.com <http://danomatika.com>
>> robotcowboy.com <http://robotcowboy.com>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20190215/5cf0d345/attachment-0001.html>