"Can't load library" after build

[jamshark70]

The Ubuntu pd-ableton-link package contains an older version that does not support the "offset" message.

So I did:

1. git clone --recursive https://github.com/libpd/abl_link.git

2. cd abl_link/external

3. make (finished successfully)

4. Add the same "external" directory into Pd's startup paths.

5. Relaunch Pd: "/blah/blah/blah/abl_link/external: can't load library"

$ ls
abl_link~.cpp          abl_link_instance.o  Makefile
abl_link~-help.pd      abl_link~.o          Makefile.pdlibbuilder
abl_link~.hpp          abl_link~.pd_linux   metronome.pd
abl_link_instance.cpp  android-ifaddrs
abl_link_instance.hpp  link

"abl_link~.pd_linux" is there, but Pd 0.50.0 seems not to like it.

What to do next?

[Ant1r]

It seems you added "/blah/blah/blah/abl_link/external" into the startup libraries (File->Preferences->Startup), so Pd tries to load "/blah/blah/blah/abl_link/external" as an external, although it should try to load "/blah/blah/blah/abl_link/external/abl_link~".

So you should remove this startup lib and add "/blah/blah/blah/abl_link/external" into the paths instead (File->Preferences−>Path); then Pd will be able to find "abl_link~" when it is called inside you patch, since it will also search in "/blah/blah/blah/abl_link/external", where it will find "abl_link~.pd_linux".

[jamshark70]

Thanks for the quick response. Indeed, that works.

I'll go ahead and close the issue, but... I'm not clear on a few points.

Take Gem, for instance. It works only if /usr/local/lib/pd/extra/Gem is in both the path and startup lists. (If it's not in the paths, then you can't create any Gem objects. If it's not a startup path, then it will try to create Gem objects but fail with a ton of undefined symbol errors.)

From this, I inferred the rule that the directory containing an external should be added in both places.

But "so Pd tries to load '/blah/blah/blah/abl_link/external'" -- sounds like, if a directory is present in the startup list, then Pd will try to load the directory itself as an external -- but, with Gem, it very clearly looks for pd_linux files within that directory. So, why, in the case of abl_link, is the startup mechanism not searching within the directory for external binaries?

And why, if it's sufficient to add abl_link to the search paths, is it not sufficient to add Gem only to the search paths?

So there are different procedures for different externals, without clear documentation. That isn't the abl_link project's problem, but it is maddening from the user's point of view.

[danomatika]

Gem is a special case and not the norm as it has both patch abstractions and binary externals. Additionally, it uses a function in newer Pds to add itself to the libs path.

For most externals, you can simply add them to the Paths dialog or, even better, add a root folder where you install externals to your path then use declare to specify the sub folder name ala externals/cyclone and [declare -path cyclone]. This is what the Pd Documents directory already does and you should already have a ~/Documents/Pd/externals folder.

What Pd does with paths is relatively simple: if you ask for an object, it checks the folder the path is in first, then it looks through any additional paths added by declare, the it checks the list of Paths set in the path dialog, then it checks some historical paths such as the internal extra folder.

[danomatika]

From this, I inferred the rule that the directory containing an external should be added in both places.

Again. Gem is special and not the norm. Wrong assumption.

And why, if it's sufficient to add abl_link to the search paths, is it not sufficient to add Gem only >to the search paths?

So there are different procedures for different externals, without clear documentation. That isn't >the abl_link project's problem, but it is maddening from the user's point of view.

We know. It is to advanced Pd users as well. This is part of the growing pains for moving from the centralized Pd-extended kitchen-sink model to decentralized packages.

The main issue comes from the fact that -path and -lib are required based on the external type, aka -path is needed when the eternal has patch abstractions or each object is compiled as one binary per-opbject while -lib is required for externals where each compiled object is join all into 1 large lib binary.

There has been some work to make both types "just work" with the -path directive, but this is not yet in a released Pd version. For now it would probably be helpful to include some instructions how how to make this external work in the readme.

[jamshark70]

The main issue comes from the fact that -path and -lib are required based on the external type, aka -path is needed when the eternal has patch abstractions or each object is compiled as one binary per-opbject while -lib is required for externals where each compiled object is join all into 1 large lib binary.

Ah, thanks, this explains it -- if abl_link is the former type (one object, one binary) and Gem is the latter (I already know it's one big bundle), then that explains it.

It would be worth explaining in help or readme -- when I put the directory into -lib and it said "can't load library," it looks like the library is incompatible and it requires a lot of background information to understand that this may not actually be the case.

Thanks for explaining!

[umlaeute]

there's a -path flag, and a -lib flag. the former is for paths/directories/folders (however your ecosystem calls them), the latter is for libraries. (the names are hopefully self-explanatory.) In almost all cases a library is a (binary) file, e.g. abl_link.pd_openbsd.

there's only one case where you would put a path into the -lib, and that is when using the libdir loader external. This was promoted with Pd-extended, but it hasn't been promoted within the last decade.

It would be worth explaining in help or readme

the problem being: which help or readme? since the described behaviour is standard, it might need to be documented in Pd's help. just as a data-point: which section of Pd's help have you consulted? (to get an idea, where people look for information, but currently don't find the relevant bits)

This is part of the growing pains for moving from the centralized Pd-extended kitchen-sink model to decentralized packages.

actually i don't think so. Pd-extended tried hard to fix this problem, but i don't think that in the end it succeeded so well. beasts like Gem never really fitted into the Pd-extended approach, and needed to be handled somewhat specially (one of those special handlings was to just load Gem by default; but that was jus a very thin veil hiding the problem)

[umlaeute]

btw, the simplest way to install [abl_link] on your Debian-based linux distribution is to just run

sudo apt install pd-ableton-link

[jamshark70]

I do appreciate the info, but I also have a feeling this issue report isn't the right place for a broader discussion. So I think I'll drop that topic at this point, perhaps later take it up again on the pd forum.

just as a data-point: which section of Pd's help have you consulted?

I did read the section on paths in Miller Puckette's most recent html manual, but still didn't understand properly what the -libs are for.

btw, the simplest way to install [abl_link] on your Debian-based linux distribution is to just run sudo apt install pd-ableton-link

That's true enough, but as noted in the first sentence of this issue report, "The Ubuntu pd-ableton-link package contains an older version that does not support the 'offset' message." And as noted in issue #20, sync is poor without using offset because it doesn't account for audio driver latency. I built my own in order to have a version that actually sounds in sync with other apps.

[umlaeute]

That's true enough, but as noted in the first sentence of this issue report, "The Ubuntu pd-ableton-link package contains an older version [...]

oops, sorry; totally missed that

[umlaeute]

That's true enough, but as noted in the first sentence of this issue report, "The Ubuntu pd-ableton-link package contains an older version [...]

oops, sorry; totally missed that

but then: Ubuntu/disco (current LTS release) and Debian/buster (current stable release) both come with pd-ableton-link==0.4, which supports the offset message.

which version of Ubuntu are you running?

[jamshark70]

which version of Ubuntu are you running?

Ubuntu Studio 18.04.

Glad to hear it's updated. I'll likely not upgrade my system now, as the semester is starting soon and I can't afford any failures.