Hello,

I wrote an external a while ago and now I cant load it anymore
it's on a respberry pi, so I did not change anything about the setup nor the version of puredata nor reinstall the box

I noticed something strange is happening, in verbose mode, it tries tons of different paths, then says it can find the external (2 times) but then it fails to create it

how can I solve/debug this ?

regards

tried /usr/lib/puredata/extra/main/main.l_arm and failed
tried /usr/lib/puredata/extra/main/main.pd_linux and succeeded <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
tried /usr/lib/puredata/extra/main/main.pd and failed
...
tried /usr/lib/puredata/extra/main.pd_linux and failed
tried /usr/lib/puredata/extra/main/main.l_arm and failed
tried /usr/lib/puredata/extra/main/main.pd_linux and succeeded <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
tried /usr/lib/puredata/extra/main.pd and failed
...
 main 13
... couldn't create

@phil123456 That is bizarre. It is normal for Pd to try many paths and the standard extensions.... but.... it says it has found it....... and I think that is the correct extension.

Too many arguments..... not enough... corrupted?
Probably not corrupted...... It looks like it created it once and not the second time.....
Is that true?
Can it not be created twice? Something to do with it reserving a variable (noob question)?
David.

no idea..and it was working for a while....

the problem is that pd complains but is not really constructive on the verbose level

also my plugin is supposed to write stuffs in the syslog, cant find anything

I used a helloworld example, same thing...wtf...

What does "..." mean? Is Pd literally printing those out?

If not, is there an error that says "maximum object loading depth 1000 reached"?

Edit: Also, what is your helloworld example?

no I just did not paste the zillion paths pd tried to open

https://github.com/pure-data/externals-howto

I dont thin the code is the issue since I tried mine and this one
I'll restart the raspberry pi

@phil123456 What's the full gcc command you're using to compile the external?

maybe your external is dynamically linked to a library that doesn't exist anymore/has a different version? idk. probably something in your setup() or new() functions I'd think

maybe I ran a package update at some time....

as stated above, I used a simpler "hello world" code, same issue

here is the code

#include "m_pd.h"

static t_class *helloworld_class;

typedef struct _helloworld {
  t_object  x_obj;
} t_helloworld;

void helloworld_bang(t_helloworld *x)
{
  post("Hello world !!");
}

void *helloworld_new(void)
{
  t_helloworld *x = (t_helloworld *)pd_new(helloworld_class);

  return (void *)x;
}

void helloworld_setup(void) {
  helloworld_class = class_new(gensym("helloworld"),
        (t_newmethod)helloworld_new,
        0, sizeof(t_helloworld),
        CLASS_DEFAULT, 0);
  class_addbang(helloworld_class, helloworld_bang);
}

here is the make file

CC= cc
 
CFLAGS= -std=gnu99 -DPD -DVERSION='"0.0"' -fPIC -O6 -funroll-loops -fomit-frame-pointer -Wall -W -g -Wno-unused-parameter  -Wno-unused-variable -Wno-unused-but-set-variable -Wno-comment -Wimplicit-function-declaration -Wint-conversion
 
INCLUDES= -I/usr/include/pd
 
LIBS= -lpng -lbcm2835 -lc
 
CFLAGS2= -rdynamic -shared -fPIC -Wl,-rpath,"\$ORIGIN",--enable-new-dtags

pd-plugin: $(patsubst %.c,build/%.o,$(wildcard *.c)) 
    $(CC) $(CFLAGS2) -o build/main.pd_linux $^ -lc -lpng  -lbcm2835

# how to build the .o files from .cpp files for the above rules
build/%.o: %.c
    $(info ----------------------------- $< -----------------------------------------------------------------------------------------------)
    @if $(CC) $(CFLAGS) $(INCLUDES) $(LIBS) -c  $< -o $@  ; then \
echo "COMPILED OK !!" ; \
else echo "ERROR" ; fi

clean:
    rm build/*

install:
    mkdir -p /usr/lib/puredata/extra/main/
    @sudo rm -rf /usr/lib/puredata/extra/main/*.*
    @sudo cp build/main.pd_linux /usr/lib/puredata/extra/main/main.pd_linux
    $(info /usr/lib/puredata/extra/main/main.pd_linux)

I removed all other instances of my main library I found on my drive, now I only get 1 "succeeded"

I updated pd

sudo apt-get install --only-upgrade pd
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'puredata-core' instead of 'pd'
puredata-core is already the newest version (0.47.1-3).
0 upgraded, 0 newly installed, 0 to remove and 232 not upgraded.

I used **pd-lib-builder **make file

same story

I found a way to debug library loading:

LD_DEBUG=libs /usr/bin/pd

...

      7840: calling init: /usr/local/lib/pd-externals/main/main.pd_linux
      7840: 
      7840: /usr/local/lib/pd-externals/main/main.pd_linux: error: symbol lookup error: undefined symbol: main_setup (fatal)
      7840: /usr/local/lib/pd-externals/main/main.pd_linux: error: symbol lookup error: undefined symbol: setup (fatal)

fixed the code and...YES

hope this also helps anyone stumbling upon this sort of issues

@phil123456 just "spitballing" - what happens if you take out all the -lpng and -lbm2835 flags
edit: just saw you used the pd-lib-builder also.. hmmm

@seb-harmonik.ar just edited, ... again ...:-)

now, my own code works just fine without modif, jee what the hell

anyway, I finaly found a way to debug PD library loading

@phil123456 I'm confused.. what was wrong? your setup function sounded like it was defined before, and it was defined in the hello world example

• in the helloworld example, the fact that I called it main while the code itself referred to helloworld
• in my own code (the one I had trouble with in the first place) ..no bloody idea

maybe the fact I cleaned all the remaining main.pd_linux on the file system solved the issue

anyway , hail to "LD_DEBUG=libs ..."

For future reference-- try the following flags to debug loading a library:

pd -noprefs -nostdpath

Run it from the same directory where your external binary is located.

Doing this prevents loading any libs or setting any paths from the preferences file. It also disables the standard paths making it more likely you will properly load your external binary instead of one located in a random place on your hard drive.

You can also debug with VSCode, which is something I recently just tried out for the first time. You'd need to install the VSCode extension C/C++, then you'd build pd-vanilla based on the instructions given on pd's website and the INSTALL.txt file, and using the --enable-debug option.

Then open the pure-data folder in VSCode, either by navigating to that folder in a terminal and typing code . or by right-clicking the folder and selecting "Open With->VSCode"

Then in VSCode, you switch to the debug pane and from a drop-down at the top of the pane, click "Add Configuration" and after selecting a config preset, a file called launch.json will pop up. You'll need to specify where the binary is. In my case, the location was:
"program": "/home/myqwil/Documents/pure-data/bin/pd",

Then lastly, and maybe there's a better way of doing this last part but the quick and easy way is just to inject your external into some part of pd's code, change the setup function so that it's static, and make sure the setup function gets called at some point, usually the setup calls are kept inside of one function at the very end of a .c file. Then it's just a matter of adding your breakpoints and re-building pd when changes are made.