Hah, ok. I suppose this is a good nudge to make a libpd 0.12.0 release then.
> On Feb 15, 2019, at 6:52 PM, Joseph Larralde <[email protected]> > wrote: > > 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> >>>> To: Giulio Moro <[email protected] <mailto:[email protected]>>, Lucas >>>> Cordiviola >>>> <[email protected] <mailto:[email protected]>>, pd-dev >>>> <[email protected] <mailto:[email protected]>> >>>> Subject: Re: [PD-dev] libpd search paths >>>> Message-ID: <[email protected] >>>> <mailto:[email protected]>> >>>> 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/> > -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
