compatibility broken with future Pd versions

[ben-wes]

based on the removal of glist_findrtext in the following commit part, pdlua won't properly load in upcoming Pd versions anymore: https://github.com/pure-data/pure-data/commit/1b928e6769bb31d3ab1220a13facb9d7f0e70406#diff-e0f324f94ffa2e22b8c83c57e7d1c7002c0859c9a5960e4013dd7434e1dbff9cL478

(learnt about this now: git log -S glist_findrtext --oneline src/g_canvas.h)

with a build from Pd's current master branch, i get:

/path/to/pdlua/pdlua.pd_darwin:dlopen(/path/to/pdlua/pdlua.pd_darwin, 0x000A): symbol not found in flat namespace '_glist_findrtext'

there is glist_getrtext with identical interface though now ...

[ben-wes]

i assume if we want to solve this on the pdlua side, we'll need to dynamically resolve symbols as we already do for the multichannel function signal_setmultiout?

should i give it a try that way? i have no idea when the next Pd release will come in - but would be good if a compatible pdlua version is waiting on deken by then.

[umlaeute]

pd-0.56 has been released, and pd-lua no longer compile because of this.

eg. see these Debian build logs

[ben-wes]

for the record: i uploaded a (temporary) version to deken two weeks ago that works with pd-0.56 (from https://github.com/ben-wes/pd-lua, which includes 3 of the PRs here and a version bump):

• https://deken.puredata.info/library/pdlua/0.12.24

... i feel a bit bad about this guerilla maintenance act though and would be glad to have it replaced with a build from the official source!

[umlaeute]

i uploaded a (temporary) version to deken [...], which includes 3 of the PRs here

@ben-wes which ones?

@agraef it would be great if ben's changes could be incorporated. and ideally bump the version of pd-lua so it doesn't conflict with ben's upload to deken.

@ben-wes i guess it would have been better to use a sub-micro version (e.g. 0.12.23.1) rather than hijacking upstream's next version.

[ben-wes]

which ones?

• #76 (which was now updated from 14c2892 to e4524e1 though)
• #78
• #79

i guess it would have been better to use a sub-micro version (e.g. 0.12.23.1) rather than hijacking upstream's next version.

true. i hesitated with this - but i did not consider a sub-micro version, which would have been a good idea. sorry, @agraef