I'm digging up some patches I made with Pd and GEM over 10 years ago, and I haven't been using Pd or GEM all this time.

Back then, Wayland was not a thing.

I've noticed now, that messages like [offset $1 $2(, and [border 0( have no effect whatsoever: the window always has a border and its position cannot be controlled. This message shows up in the console:

Wayland: The platform does not support setting the window position.

How the people who designed Wayland could think that that was fine is beyond me, but anyway, I see that applications that run on XWayland actually can control window position (window.moveTo() works in most browsers, so...).

Is it possible to tell GEM to use XWayland? Does that fix border 0 too? Or what do people using GEM (or any video-mapping, VJing, and other audiovisual applications for that matter) do? Just switch to an X11 session every time (and hope it won't crash because of one of its countless bugs that will never be fixed)?

Does this forum not send email notifications when a topic you create gets replies? I didn't get any.

Anyway...

My patch used Vanilla plus GEM and a few externals. I got all the updated versions of all the externals and Gem.
Gem is the one that's causing most of the trouble... or rather all of the trouble.

I get GL stack underflows, crashes when closing the gemwin, "someone sent a bogus pointer..." and other errors, none of which existed back when I created the patch. I have started reporting the bugs to Gem, but it's hard to isolate them, narrow them down and create minimal reproducing examples, as the patch is very, very complex, and the last time I touched it (and Pd) 12 years ago it was running seamlessly and very stable. I also tested on Windows and it's even worse: there it crashes when opening the gemwin.

My goal is not to use the old version of Pd and Gem to run the patch. That would be my very, very last resort. One one hand I suspected a bc-breaking change in how Pd handled some kinds of messages and wanted to test that, but I have already discarded that; on the other hand I wanted to see if I could run the patch without issues on the old versions, and from there either (a) start trying to narrow down the issues, always comparing between the two versions (because I don't remember how half of the stuff works, so if I reduce it to a minimal patch and still get issues, I'm never sure whether I'm introducing errors in the patch) or maybe (b) offer the Gem developers my whole patch (I cannot publish it but I would trust them) as a black box that certainly triggers a bunch of bugs even though it's very far from a minimal test case. I can still do that but it would be nice to confirm that the patch runs with no errors with the older version on a modern machine and OS.

In the end I was able to compile Pd 0.43-3 (pretty sure it would have been the same with 0.43-4) with the "new" build system by using CXXFLAGS="-std=c++98" for configure.

Now I have another issue:

Pd runs but only if I launch it from the correct folder. That is if I do from a terminal:

cd /path/to/pd-043-3/src
pd

it works (that is where the compiled binary was created; anyway everything holds true if I move it to ../bin/).
But if I do:

cd /path/to/pd-043-3
src/pd

then I get the error:

Error in startup script: couldn't read file "../tcl//pd-gui.tcl": no such file or directory

Not a huge deal, I can write a shell script that cds into the directory and runs pd, but it makes me think that something is not quite right.

I'm also trying and unable to compile the old version of Gem, but I'll open a separate thread about that.

Hi!

I'm digging up some old Pd patches that I wrote ages ago which no longer work on the current Pd version, and I need to run Pd 0.43 to compare some behaviors between the current version and that version.

Since I couldn't find any binaries at https://puredata.info/downloads/pure-data/releases/0.43.4, I downloaded the source code and I'm trying to compile it on Manjaro Linux.

Following the instructions in INSTALL.txt, it says there are two build systems, an "old" and a "new" one. I tried both and they fail with apparently very different issues.

With the "new" build system, when running make I get:

(...)
/usr/bin/ld: pd-s_audio_oss.o:(.bss+0x8): multiple definition of `sys_soundout'; pd-s_audio.o:(.bss+0x8): first defined here
/usr/bin/ld: pd-s_audio_oss.o:(.bss+0x0): multiple definition of `sys_soundin'; pd-s_audio.o:(.bss+0x0): first defined here
/usr/bin/ld: pd-s_audio_oss.o:(.bss+0x10): multiple definition of `sys_dacsr'; pd-s_audio.o:(.bss+0x10): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:706: pd] Error 1
make[2]: Leaving directory '/home/teo/programmi/puredata/releases/043-4/pd-0.43-4/src'
make[1]: *** [Makefile:919: all-recursive] Error 1
make[1]: Leaving directory '/home/teo/programmi/puredata/releases/043-4/pd-0.43-4'
make: *** [Makefile:819: all] Error 2

With the "old" build system, when running ./configure I get:

(...)
checking tcl.h usability... yes
checking tcl.h presence... yes
checking for tcl.h... yes
checking for main in -ltcl85... no
checking for main in -ltcl8.5... no
checking for main in -ltcl84... no
checking for main in -ltcl8.4... no
checking for main in -ltcl8.3... no
checking for main in -ltcl8.2... no
checking for main in -ltcl8.0... no
no tcl library found

Any idea how to fix either?

Thanks