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>


_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev

Reply via email to