Hi list,
for all the lonely souls sitting on IRIX machines I have compiled Pd 0.38-0test7 for IRIX. Seems to work just fine, even the new (and cool) features....
Had to change some files slightly:
s_inter.c s_audio.c s_audio_sgi.c t_tkcmd.c and the makefile
Most of the changes were just some new #ifdefs that were Linux only but work on IRIX the same way.
Miller, maybe you can merge these changes into your code????
Ah, of course, download is here: http://www.nullmedium.de/dev/irix/pd-0.38-0test7-irix.tar.gz
Olaf
for all the lonely souls sitting on IRIX machines I have compiled Pd 0.38-0test7 for IRIX. Seems to work just fine, even the new (and cool) features....
-Thank you/Thank you/Thank you/Thank you/Thank you/
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
Yes thank you Olaf Now GEM please :-)
On Friday, November 5, 2004, at 04:21 PM, Arie van Schutterhoef wrote:
for all the lonely souls sitting on IRIX machines I have compiled Pd 0.38-0test7 for IRIX. Seems to work just fine, even the new (and cool) features....
-Thank you/Thank you/Thank you/Thank you/Thank you/
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # | | http://www.schreck.nl/ | | http://www.xs4all.nl/~schreck/ | ` *===========================================================++ ` |Compositions http://www.xs4all.nl/~schreck/html/compo.html | ` |Samples http://www.xs4all.nl/~schreck/html/samp.html | ` |Patches http://www.xs4all.nl/~schreck/html/pat.html | ` |Videos http://www.xs4all.nl/~schreck/html/video.html | ` |Scores http://www.xs4all.nl/~schreck/html/scores.html | *===========================================================++. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Yes thank you Olaf Now GEM please :-)
-That's a good idea...
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
Resurrecting yet another old thread here. I have compiled pd 0.40 for IRIX, it has about the same file structure what Olaf compiled above (0.38), it runs after some compiler related updates. There was a notable change for the 0.38 release with respect to platform dependent file structure as compared to earlier versions.
However, I cannot make audio work, it comes back with "consistency check failed: cos~: unexpected machine alignment". Anyone has a clue, or by change is there Olaf's IRIX update for pd 0.38 still floating around (nullmedium server is gone...)?
Thanks much, Wolfgang
...it appears to solve some problems, I just need to post about them first ;) Problem solved: the endian logic in d_osc.c which is initially correctly defined in the first few lines of code, was overridden by yet another logic to determine HIOFFSET and LOWOFFSET for endianness. Works now, SGI Irix 6.5 with Pd 0.40, analog stereo audio, ADAT, Midi (even selectable from the GUI menu).
On 1/12/26 01:52, Wolfgang Gaggl wrote:
...it appears to solve some problems, I just need to post about them first ;) Problem solved: the endian logic in d_osc.c which is initially correctly defined in the first few lines of code, was overridden by yet another logic to determine HIOFFSET and LOWOFFSET for endianness. Works now, SGI Irix 6.5 with Pd 0.40, analog stereo audio, ADAT, Midi (even selectable from the GUI menu).
great to see you proceed.
in the meantime, i found an emulator for the SGI Indy [1], and tried to build the latest and greatest Pd (0.56-2), but I'm afraid I made less progress than you did...
the disk image has IRIX-6.5 (6.5.22 iirc) and came with a number of freeware tools installed, including gcc and autotools, so in theory it should have worked.
(in the meantime i've managed to complete break my disk, so the report below is from the top of my head and might be lacking some important details)
# autotools
unfortunately, the autotools version installed (no idea which version) was just too old. this was easily circumvented by just running autoreconf on a modern machine and copy the generated files to the indy (the proper way would have been to do a "make dist" and copy the generated tarball)
# configure
the current configure script uses "grep -w", which is not available on IRIX-6.2 [2820] this appears to be a minor issue (some tests will fail, that probably would have failed anyhow) i simply ignored this, and i got some Makefiles
configure detected and used the installed 'gcc' (GCC 3.3! yay!)
# make
the generated Makefile uses some modern(?) GNU make trickery to set the
WISHDEFINE and DEKEN_DEFINE makevars to some preprocessor macros, which
the installed version of 'make' didn't like.
i simply set these make variables to empty strings on the cmdline (make WISHDEFINE="" DEKEN_DEFINE="") to bypass this.
also, the top-level makefile uses make -C <path> to build the various
subprojects, which installed make did not understand.
i simply ignored this and ran 'make' directly in src/
probably running 'gmake' instead of 'make' would have fixed both issues.
# source: endianness detection
the current code to detect endianness did not work (as you discovered). with newer versions of Pd, all the endianness detection code is now in m_private_utils.h, so I fixed it there.
# source: C99 with the above, I managed to build all of src/, with the notable exception of src/x_vexp_fun.c [expr] uses C99 features (like 'isnan()' [79865015]), and this is where my adventure ended.
the system (math.h!) are specific to the MIPSpro compiler (using some
private __generic macro that is not available on gcc)
about missing licenses, but this can be ignored. unfortunately, the disk image lacks the actual backend compiler /usr/lib32/cmplrs/fec, so the MIPSpro compiler is not usable. funnily, the MIPSpro C++ compiler (using /usr/lib32/cmplrs/fecc as backend) did work.
this is where my little adventure ended: i tried to (re)install some packages that should provide the (MIPSpro) C-compiler, but this uninstalled half of the system and now it doesn't boot any more.
I didn't try to build Pd with the c++ compiler (as this typically does not work), and now it's too late to try...
of course, even if i did manage to compile, the audio backend for the SGI had been removed for the Pd-0.41; but I guess it would be possible to ressurect it from the release history
fmdasdr IOhannes
[1] https://forums.irixnet.org/thread-4081.html [2820] https://github.com/pure-data/pure-data/issues/2820 [79865015] https://stackoverflow.com/questions/79865015
On 1/12/26 11:10, IOhannes m zmoelnig via Pd-list wrote:
On 1/12/26 01:52, Wolfgang Gaggl wrote:
...it appears to solve some problems, I just need to post about them first ;) Problem solved: the endian logic in d_osc.c which is initially correctly defined in the first few lines of code, was overridden by yet another logic to determine HIOFFSET and LOWOFFSET for endianness. Works now, SGI Irix 6.5 with Pd 0.40, analog stereo audio, ADAT, Midi (even selectable from the GUI menu).
great to see you proceed.
in the meantime, i found an emulator for the SGI Indy [1], and tried to build the latest and greatest Pd (0.56-2), but I'm afraid I made less progress than you did...
so there's been some partial success now:
# make
the generated Makefile uses some modern(?) GNU make trickery to set the WISHDEFINE and DEKEN_DEFINE makevars to some preprocessor macros, which the installed version of 'make' didn't like. i simply set these make variables to empty strings on the cmdline (
make WISHDEFINE="" DEKEN_DEFINE="") to bypass this.also, the top-level makefile uses
make -C <path>to build the various subprojects, which installed make did not understand. i simply ignored this and ran 'make' directly in src/probably running 'gmake' instead of 'make' would have fixed both issues.
indeed, using 'gmake' rather than the normal "make" fixed these issues.
# source: C99 with the above, I managed to build all of src/, with the notable exception of src/x_vexp_fun.c [expr] uses C99 features (like 'isnan()' [79865015]), and this is where my adventure ended.
- the installed gcc is apparently C99-capable, but the header files on
the system (math.h!) are specific to the MIPSpro compiler (using some private
__genericmacro that is not available on gcc)
- the installed MIPSpro C compiler (which also supports C99) warns a lot
about missing licenses, but this can be ignored. unfortunately, the disk image lacks the actual backend compiler /usr/lib32/cmplrs/fec, so the MIPSpro compiler is not usable. funnily, the MIPSpro C++ compiler (using /usr/lib32/cmplrs/fecc as backend) did work.
so i've simple removed the [expr] sources for now, and lo and behold! the compilation succeeded.
well, at least after i provided a stub for "strnlen()" (which is POSIX-2008). and manually added a "-lpthread" (for whatever reasons, configure thought i don't need it).
of course there is no sound. and no GUI (heck, even connecting to a remote GUI doesn't work for now)
but i can run a test-patch that produces a sinewave and records it to a good old .snd file. or an aiff file. .caf file kind-of-works (audacity can read it; but sndfile-info reports an error) .wav files don't work
fgmasdr IOhannes
Hi IOhannes, wow, great progress! I admire the bravery to jump right into compiling the latest and greatest for Irix.
Re GUI: What version of tcltk do you think we can make this work on? I have tcltk-8.4.9 as the latest I could find so far for Irix (which works fine for Pd 0.40).
Cheers, Wolfgang
Am 12. Jänner 2026 16:07:03 MEZ schrieb Wolfgang Gaggl wgaggl1@gmail.com:
Hi IOhannes, wow, great progress! I admire the bravery to jump right into compiling the latest and greatest for Irix.
Re GUI: What version of tcltk do you think we can make this work on? I have tcltk-8.4.9 as the latest I could find so far for Irix (which works fine for Pd 0.40).
ideally we could use at least Tcl/Tk 8.5 (afair there's a bit of code that relies on 8.5; there's a fair bit of compat code, but the less backward compatible we need to be the better). and to be honest, I don't know whether the current GUI will actually work with 8.4
I'm currently trying to build the last 8.6 release of Tcl/Tk... let's see how this works out.
mfg.sfg.jfd IOhannes
On 1/12/26 17:17, IOhannes m zmölnig via Pd-list wrote:
Am 12. Jänner 2026 16:07:03 MEZ schrieb Wolfgang Gaggl wgaggl1@gmail.com:
I'm currently trying to build the last 8.6 release of Tcl/Tk... let's see how this works out.
good news: Tcl/Tk-8.6.17 build fine (the only issue was with some extra Tcl-packages like "sqlite", but since we don't need them i just skipped them... and wish starts :-)
bad news: the GUI still doesn't fire up:
X Error of failed request: BadLength (poly request too large or
internal Xlib length error)
Major opcode of failed request: 18 (X_ChangeProperty)
Serial number of failed request: 68
Current serial number in output stream: 70
gmasdr IOhannes
On 1/12/26 19:25, IOhannes m zmoelnig via Pd-list wrote:
On 1/12/26 17:17, IOhannes m zmölnig via Pd-list wrote:
Am 12. Jänner 2026 16:07:03 MEZ schrieb Wolfgang Gaggl wgaggl1@gmail.com:
I'm currently trying to build the last 8.6 release of Tcl/Tk... let's see how this works out.
good news: Tcl/Tk-8.6.17 build fine (the only issue was with some extra Tcl-packages like "sqlite", but since we don't need them i just skipped them... and wish starts :-)
bad news: the GUI still doesn't fire up:
well, it seems i have resolved most issues. the GUI finally starts, and I have re-added the sgi audio and MIDI backends.
the changeset can be found in the irix branch of my fork on
https://github.com/umlaeute/pure-data/tree/irix
# usage
https://www.tcl-lang.org/software/tcltk/download.html (I didn't try Tcl/Tk-9.x) compile and install both Tcl and Tk. (as mentioned previously, I couldn't build some of the Tcl addons; simply remove the offending directories from tcl8.6.17/pkgs/; i left in the itcl and thread packages; no idea whether they are needed)
rm -rf tcl8.6.17/pkgs/tdbc* tcl8.6.17/pkgs/sqlite*
cd tcl8.6.17/unix
./configure
gmake
gmake install
cd ../../tk8.6.17/unix
./configure
gmake
gmake install
git clone https://github.com/umlaeute/pure-data -b irix
./autogen.sh
./configure --without-local-portaudio --without-local-portmidi \
--disable-expr --with-wish=/usr/local/bin/wish8.6 \
--with-external-extension=pd_irix6 \
--with-deken-os=Irix6 --with-deken-cpu=mips
gmake
Tcl/Tk's "gmake install" installed wish to /usr/local/bin/wish8.6, and Pd tries to just open "wish" by default, hence the "--with-wish" flag. so alternatively you could just make sure that /usr/local/bin is in your PATH, and symlink "wish8.6" to "wish".
the "--with-deken-*" flags are optional and are actually only used for deken (and there probably aren't any Irix specific packages...)
sometimes, I get failures when building the po/ directory (some unknown flag to xgettext). just running gmake again seems to do the trick.
./bin/pd
(if things go awry, use "./bin/pd -stderr" first)
I had some IPv6-related problems when connecting the pd-gui with the core (in theory IRIX should support IPv6, but it who knows...)
a simple solution is to just force to IPv4, by patching src/s_net.c (forcing the hints.ai_flags to AI_PASSIVE):
diff --git a/src/s_net.c b/src/s_net.c
index 48bed722..4134988f 100644
--- a/src/s_net.c
+++ b/src/s_net.c
@@ -66,6 +66,7 @@ int addrinfo_get_list(struct addrinfo **ailist, const
char *hostname,
AI_V4MAPPED | /* fallback to IPv4-mapped IPv6
addrs */
#endif
AI_PASSIVE; /* listen to any addr if hostname
is NULL */
+ hints.ai_flags = AI_PASSIVE;
portstr[0] = '\0';
sprintf(portstr, "%d", port);
result = getaddrinfo(hostname, portstr, &hints, ailist);
i'd be interested to know whether this works at all. and whether audio (and MIDI!) works as well.
there seems to be some problem with printing numbers. e.g. [noise~]->[env~]->[print] shows weird numbers, like "0+.3345" or "/4.909"
due to the nature of the my VM, I could not actually test sound input/output.
of course, my VM is absymally slow (and the Irix is not an Octane :-)).
happy patching.
gamsdr IOhannes
On 1/13/26 16:35, IOhannes m zmoelnig via Pd-list wrote:
well, it seems i have resolved most issues. the GUI finally starts, and I have re-added the sgi audio and MIDI backends.
of course i forgot the most important thing: a screenshot of the actual thing (see attachment)!
and another note about building:
- build
./autogen.sh ./configure --without-local-portaudio --without-local-portmidi \ --disable-expr --with-wish=/usr/local/bin/wish8.6 \ --with-external-extension=pd_irix6 \ --with-deken-os=Irix6 --with-deken-cpu=mips gmake
configure happily detects and uses my installed 'gcc' compiler. i have not tried with another compiler (like MIPSpro), as this doesn't work on my VM.
please report your success if you try with MIPSpro or something else.
gas,mdr IOhannes
gasdmr IOhannes
That, Sir, is absolutely fantastic news!!!!
I'll try to get to it very soon and will report back.
Cheers, Wolfgang
Got the prerequisites installed on my SGI and downloaded your Pd-Irix branch.
I'm getting stuck at the ./autogen.sh step, since I don't have autotools installed on my SGI. I've looked at what's needed, and there are many dependencies that need to be met to install autotools.
Since you mentioned that you had issues with autoreconf and did it on another machine, can you provide me with the the output file(s) so I can skip that step (would this allow me to skip the whole autogen.sh steps or only that autoreconf execution within autogen.sh)?
Thanks, Wolfgang
You could try the distribution source tarball from Miller's site which will have the configure script generated or do it on a separate machine yourself (not on the SGI) then copy the result over via: make dist
On Jan 14, 2026, at 12:56 AM, Wolfgang Gaggl wgaggl1@gmail.com wrote:
Got the prerequisites installed on my SGI and downloaded your Pd-Irix branch.
I'm getting stuck at the ./autogen.sh step, since I don't have autotools installed on my SGI. I've looked at what's needed, and there are many dependencies that need to be met to install autotools.
Since you mentioned that you had issues with autoreconf and did it on another machine, can you provide me with the the output file(s) so I can skip that step (would this allow me to skip the whole autogen.sh steps or only that autoreconf execution within autogen.sh)?
Thanks, Wolfgang
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/6OZDP45OOV...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Am 14. Jänner 2026 01:27:40 MEZ schrieb Dan Wilcox danomatika@gmail.com:
You could try the distribution source tarball from Miller's site which will have the configure script generated
I didn't know that miller is still providing dist tarballs (even when not using git to clone the sources, these days I mostly just grab the tarballs from GitHub...)
in any case: this won't help much, as we are taking about a branch (on top of the last release) that has modifications to the build system (so configure and friends do have to be regenerated)
or do it on a separate machine yourself (not on the SGI) then copy the result over via: make dist
yes that is what needs to be done.
the dependencies to generate the build system are: autoconf, automake & libtool
@Wolfgang you couldn't run autoreconf on the octane (which was kind of expected), but you got "similar errors" on your Linux box. without knowing the actual errors, I guess they were different enough and actually referred to a missing "libtool" installation (which I think is the most common mistake to make).
as forautoreconf vs autogen.sh: the latter is really just a wrapper around the former that has some fallback mechanism to manually call autoconf, automake, aclocal & libtool.
so if you can, you can also just run autoreconf -fiv *instead*.
mfg.sfg.jfd IOhannes
Thanks for the helpful replies.
I updated libtools on my Linux box, ran autoconf.sh and got configure. Moved it all to the SGI and ran configure ok.
Now on to gmake ... Ran ok, started ./bin/pd didn't run. Looking at stderr output: error: bind: Address family not supported by protocol family (124).
Still looks like an IPv6 issue, albeit s_net.c has the AI_PASSIVE force in it.
On 1/14/26 15:18, Wolfgang Gaggl wrote:
Thanks for the helpful replies. I updated libtools on my Linux box, ran autoconf.sh and got configure. Moved it all to the SGI and ran configure ok.
Now on to gmake ... Ran ok, started ./bin/pd didn't run. Looking at stderr output: error: bind: Address family not supported by protocol family (124).
Still looks like an IPv6 issue,
looks like it.
albeit s_net.c has the AI_PASSIVE force in it.
are you absolutely sure? (my branch does not contain this fix; neither does the tarball i sent you off list)
because this is exactly the error I get when hints.ai_flags contain the AI_V4MAPPED flag. the X Error I was getting was triggered, when the hints.ai_flags contain the AI_ALL flag.
so at least for me, hints.ai_flags must be *exactly* AI_PASSIVE.
gas,dr IOhannes
Installed autotools (albeit v2.57 while the script asks for >=2.59) go the following errors:
IRIS 11% ./autogen.sh
autoreconf: Entering directory .' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I m4/generated -I m4 --output=aclocal.m4t autoreconf:aclocal.m4' is unchanged
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
You should update your aclocal.m4' by running aclocal. autoreconf: running: aclocal -I m4/generated -I m4 --output=aclocal.m4t autoreconf:aclocal.m4' is unchanged
autoreconf: running: /usr/freeware/bin/autoconf --force
configure.ac:8: error: possibly undefined macro: AC_CONFIG_MACRO_DIR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:15: error: possibly undefined macro: AS_IF
configure.ac:17: error: possibly undefined macro: AC_MSG_WARN
configure.ac:26: error: possibly undefined macro: AS_CASE
configure.ac:245: error: possibly undefined macro: AC_PROG_MKDIR_P
configure.ac:246: error: possibly undefined macro: AC_PROG_GREP
configure.ac:247: error: possibly undefined macro: AC_PROG_SED
configure.ac:274: error: possibly undefined macro: AC_TYPE_INT16_T
configure.ac:275: error: possibly undefined macro: AC_TYPE_INT32_T
configure.ac:281: error: possibly undefined macro: AC_DEFINE
configure.ac:317: error: possibly undefined macro: AC_CHECK_FUNCS_ONCE
configure.ac:417: error: possibly undefined macro: AS_HELP_STRING
autoreconf: /usr/freeware/bin/autoconf failed with exit status: 1
I also ran this on a Linux machine with a much newer autoconf (2.71), got similar failure (complaining about possibly missing macros). Can't generate configure file.
On 1/13/26 16:35, IOhannes m zmoelnig via Pd-list wrote:
there seems to be some problem with printing numbers. e.g. [noise~]->[env~]->[print] shows weird numbers, like "0+.3345" or "/4.909"
mistral.ai says that this is a "well known bug" on IRIX, and gives a couple of suggestions on how to fix it (none of which work of course; the time has yet to come when an LLM will give me a code suggestions that actually works).
i can reproduce the problem with this trivial program:
#include <stdio.h>
int main() {
int i;
for(i=30; i<=40; i++) {
double f=(double)i;
printf("%d\t%f\t%.1f\n", i, f, f);
}
return 1;
}
i thought that the problem might be related to using gcc, but apparently the issue persists when compiling with 'CC' (provided by MIPSpro; for unknown reasons this compiler appears to work, unlike the 'cc' (lower case) variant).
I'm currently trying to fix the MIPSpro installation, but i just noticed that even the software manager (swmgr) shows the same broken numbers, so I guess the problem lies deeper.
anyhow, on the plus side: i managed to fix the "expr" compilation; so now Pd-0.56-2 should be "feature complete", barring the audio/MIDI system which is still untested.
while you are trying to fix the networking issue, you could test whether audio is working with a simple [osc~ 440]->[dac~] patch running without a GUI...
gfasmnrd IOhannes
That's great, can't wait to try this out tonight!
Re IPv6, you are right, it was still allowing all, will fix when recompiling it.
Re expr~ I assume I need to re-download your branch to compile this?
Will report back once I get to it.
Thanks much!
Good news first: !!! Pd 0.56-2 plays out audio on SGI Octane with Irix 6.5.22 !!! Used a test.pd script with an osc~ and dac~ object. Audio sounds clean.
Not so good news: I can't load a GUI yet. After forcing AI_PASSIVE the net bind issue goes away but now I get what you had earlier: RIS 12% ./bin/pd X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 18 (X_ChangeProperty) Serial number of failed request: 44 Current serial number in output stream: 46 read from GUI socket: No such file or directory; stopping gui socket 4 - closing audio... closing MIDI... ... done.
IOhannes, Is there something else you did to prevent this issue?
More updates on SGI: Pd 0.56 in -nogui mode is confirmed to work with analog stereo I/O as well as the ADAT interface, and also MIDI! Note that -inchannels 8 and -outchannels 8 need to be specified on command line for ADAT to avoid a core dump failure. For MIDI, -midiindev 1 and -midioutdev 1 need to be specified at start.
For gui mode, I'm still struggling with the X Error above, it seems different from the previous net bind error (that was addressed by forcing AI_PASSIVE).
Wolfgang
Am 15. Jänner 2026 15:39:25 MEZ schrieb Wolfgang Gaggl wgaggl1@gmail.com:
More updates on SGI: Pd 0.56 in -nogui mode is confirmed to work with analog stereo I/O as well as the ADAT interface, and also MIDI! Note that -inchannels 8 and -outchannels 8 need to be specified on command line for ADAT to avoid a core dump failure. For MIDI, -midiindev 1 and -midioutdev 1 need to be specified at start.
this is great news!
For gui mode, I'm still struggling with the X Error above, it seems different from the previous net bind error (that was addressed by forcing AI_PASSIVE).
hmm. I'm afraid that I have no idea. the issue was resolved more or less "magically" here. as previously said here, I can still trigger this (or a similar) error if my aiflags include AI_ALL, but apart from that it just seems to work.
sorry for not being of more help.
another thing that I would like to get clarified: a mentioned previously, my Pd (and actually the entire system), has problems printing floating point numbers. among other things, this can lead to weird errors in the GUI (come to think of it, it*might* even trigger something like that XError...¹). a simple check whether your system is affected, would be something like this
[loadbang] | [float 56.78] | [print]
(here this will replace some characters of the number with other characters) I've asked on some IRIX forum and they said that this should be a problem with my emulator and not happen on a physical machine, but I'd like to have a confrontation on this.
mfg.sfg.jfd IOhannes
¹ you could try starting Pd with '-d 1' to see the data that is being sent to the GUI, and check for any weirdnesses
IOhannes, Floating point numbers work fine on the physical machine, I just confirmed.
Can you start pd in the Irix VM with -d and send me the output please, I'd like to compare it to what I get here. That might help to pinpoint where it went wrong.
Thanks, Wolfgang
On 15/01/2026 20:51, Wolfgang Gaggl wrote:
IOhannes, Floating point numbers work fine on the physical machine, I just confirmed.
Can you start pd in the Irix VM with -d and send me the output please, I'd like to compare it to what I get here. That might help to pinpoint where it went wrong.
not before monday. but in the meantime, you can post the output you get, maybe I (or somebody else) can sport something.
gdsamr IOhannes
IRIS 53% ./bin/pd -d 1
::dialog_path::set_paths {} {} {{./extra} } ; ::dialog_startup::set_libraries {} ; set_escaped ::sys_verbose 0 set_escaped ::sys_use_stdpath 1 set_escaped ::sys_defeatrt 0 set_escaped ::sys_zoom_open 0 ::dialog_startup::set_flags {} ; pdtk_pd_startup 0 56 2 {} {} {} {Speedo} normal ::deken::set_platform {Irix6} {mips} 32 32 ; set pd_whichapi 6 pdtk_pd_dsp {OFF} ; set pd_whichmidiapi 0 ;
X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 18 (X_ChangeProperty) Serial number of failed request: 44 Current serial number in output stream: 46
set pd_whichmidiapi 0 ;
read from GUI socket: No such file or directory; stopping gui socket 4 - closing audio... closing MIDI... ... done.
IRIS 53% ./bin/pd -d 1 ::dialog_path::set_paths {} {} {{./extra} } ; ::dialog_startup::set_libraries {} ; set_escaped ::sys_verbose 0 set_escaped ::sys_use_stdpath 1 set_escaped ::sys_defeatrt 0 set_escaped ::sys_zoom_open 0 ::dialog_startup::set_flags {} ; pdtk_pd_startup 0 56 2 {} {} {} {Speedo} normal ::deken::set_platform {Irix6} {mips} 32 32 ; set pd_whichapi 6 pdtk_pd_dsp {OFF} ; set pd_whichmidiapi 0 ; X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 18 (X_ChangeProperty) Serial number of failed request: 44 Current serial number in output stream: 46 set pd_whichmidiapi 0 ; read from GUI socket: No such file or directory; stopping gui socket 4 - closing audio... closing MIDI... ... done.
TL;DR: try these
wish tcl/pd-gui.tcl)On 16/01/2026 00:00, Wolfgang Gaggl wrote:
IRIS 53% ./bin/pd -d 1 Pd>> ::dialog_path::set_paths {} {} {{./extra} } ; Pd>> ::dialog_startup::set_libraries {} ; Pd>> set_escaped ::sys_verbose 0 Pd>> set_escaped ::sys_use_stdpath 1 Pd>> set_escaped ::sys_defeatrt 0 Pd>> set_escaped ::sys_zoom_open 0 Pd>> ::dialog_startup::set_flags {} ; Pd>> pdtk_pd_startup 0 56 2 {} {} {} {Speedo} normal Pd>> ::deken::set_platform {Irix6} {mips} 32 32 ; Pd>> set pd_whichapi 6 Pd>> pdtk_pd_dsp {OFF} ; Pd>> set pd_whichmidiapi 0 ; X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 18 (X_ChangeProperty) Serial number of failed request: 44 Current serial number in output stream: 46 Pd>> set pd_whichmidiapi 0 ; Pd read from GUI socket: No such file or directory; stopping Pd gui socket 4 - Pd closing audio... Pd closing MIDI... Pd ... done.
thanks, i don't see anything weird here. (except that I do not know where the the "Speedo" font comes from, presumably from some .pdsettings file that you imported.
here's about mine (this is run via a non X-forwarding ssh connection on
a very remote machine, where I cannot actually start the GUI, so I just
used netcat to fake a GUI.
root@IRIX: /> pd -stderr -verbose -verbose -d 1
Pd-0.56.2 ("") compiled 11:03:10 Jan 14 2026
float precision = 32 bits
>> ::dialog_path::set_paths {{/Pd/externals} } {}
{{/usr/local/lib/pd/extra} } ;
>> ::dialog_startup::set_libraries {} ;
>> set_escaped ::sys_verbose 2
>> set_escaped ::sys_use_stdpath 1
>> set_escaped ::sys_defeatrt 0
>> set_escaped ::sys_zoom_open 0
>> ::dialog_startup::set_flags {} ;
>> pdtk_pd_startup 0 56 2 {} {} {} {DejaVu Sans Mono} bold
>> ::deken::set_platform {Irix6} {mips} 32 32 ;
>> set pd_whichapi 6
>> pdtk_pd_dsp {OFF} ;
>> set pd_whichmidiapi 0 ;
input channels = 2, output channels = 2
no serial ports are configured for MIDI;
if you want to use MIDI, try exiting Pd, typing
'startmidi -d /dev/ttyd2' to a shell, and restarting Pd.
>> set pd_whichmidiapi 0 ;
Pd: signal 2
gui socket 3 -
closing audio...
closing MIDI...
... done.
(sidenote: i see that the ">>" prefix for messages sent to the Pd-GUI show up like quotes in the MUA, and therefore you tried to cleanup the output (in your 2nd mail) to strip away the prefix. I think it is better to leave them alone for now)
what i find slightly strange is, that the X Error is *surrounded* by
calls to set pd_whichmidiapi (so it's being called twice; it usually
is only called once).
what happens if you completely disable MIDI for now? (-nomidi)
(I don't really think it might change anything, but right now I have run
out of ideas so anything might be worth trying)
... on re-testing on my linux box i get the double call to set pd_whichmidiapi as well, so it probably isn't so strange after all.
i guess this means that the MIDI subsystem is initialized twice (which
probably should be fixed anyhow).
and it *might* just be that this initialization triggers a race
condition on your system, so starting without MIDI might indeed change
something here.
another thing I remembered is, that when I had the X Error problem, one thing I tried was starting Pd via the GUI (rather than starting the GUI via Pd).
wish8.6 tcl/pd-gui.tcl
or (with more debugging)
wish8.6 tcl/pd-gui.tcl -stderr -pdarg "-stderr -verbose -verbose -d 3"
by changing the startup order, the GUI might just get enough breath that it can properly initialize. this wouldn't explain why I can start the GUI from the core; esp. since my CPU is much slower anyhow (100MHz) and it's emulated as well, so it's even below that nominal clock speed and probably with a lot of jitter (I get kernel panics every now and then when accessing data over NFS which I think is somewhat related to slow speed and timing; but I disgress). unless of course TclTk does some JIT and caches the byte-compiled objects, which would speed up the entire startup process considerably, after it succeeded once. but I somehow doubt this.
gfmadsr IOhannes
Hi IOhannes,
thank you for good troubleshooting suggestions, albeit with no obvious solution:
->When putting a stderr output message at the start of that function followed by a sleep(10) command, the message appears but error occurs ~10+ seconds later, so happened after that code -> When putting a stderr message at the end of that function followed by a sleep(10) command, the message appears and the error appears, everything else (like both midi notifications) happens later, so the error appears to be triggered earlier than the sleep() command but took a while to produce a message. Actually it looks like it happened around that fork() call in this function. So a race condition may be possible between the parent and child of the fork (or it took a while for one or the other to die from different reasons...).
I'm keeping digging but am hoping there's some configuration details that I missed.
Cheers, Wolfgang
Apparently it dies when it tries to start pd-gui.tcl in s_inter.c. Parent pd process continues while child process is trying to pull up the gui and eventually fails with the X Error.
/bin/sh -c 'TCL_LIBRARY="./lib/tcl/library" TK_LIBRARY="./lib/tk/library" /usr/local/bin/wish8.6 "./tcl/pd-gui.tcl" 1127'
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 18 (X_ChangeProperty)
Serial number of failed request: 68
Current serial number in output stream: 70
Note: The specified TCL_LIBRARY and TK_LIBRARY folders don't exist in my installation, but even when creating those links it fails. Noteworthy, the screenshot from IOhannes shows the same command line with -verbose execution.
Not sure what to make of it.
Am 18. Jänner 2026 02:28:58 MEZ schrieb Wolfgang Gaggl wgaggl1@gmail.com:
Apparently it dies when it tries to start pd-gui.tcl in s_inter.c. Parent pd process continues while child process is trying to pull up the gui and eventually fails with the X Error.
can you start wish8.6 on its own?
some more things I did when I faced these problems were to just liberally sprinkle printf-debugging messages into pd-gui.tcl
things like puts "variables initialised"
(luckily there's no need to rebuild after such a change)
apparently for me started to work before I could nail down the issue... but maybe it will reveal more to you.
mfg.sfg.jfd IOhannes
Tried a couple of things: Installed tcltk8.5.7, which should work with Irix 6.5.22, confirmed same X Error failure.
Sprinkled puts messages very generously across pd-gui.tcl including adding a "after 5000" before comments to allow XServer delayed messages to appear at the time they actually happened in the code (granted, 5000 may have been needlessly large).
Narrowed the issue down to when create_window is called in function pdtk_pd_startup in pd-gui.tcl. Followed this down to pdwindow.tcl, where it fails at "raise .pdwindow" in function create_window. When commenting out that raise line, it fails at "tkwait visibility .pdwindow.text" in function create_window_finalize. If commenting the visibility line out, it fails later when trying to interact with .pdwindow.
It appears to me that whenever .pdwindow is to be shown on the screen it fails, likely due to some properties pf .pdwindow set prior.
Wolfgang
I finally found the issue that crashed the GUI of Pd 0.56.2 on Irix 6.5.22! It was the pd.gif icon. Icons in Irix are .xpm files. This should be a configure update.
IOhannes, if the gif icon works on the Mame emulator, it's because it's patched with Nekoware stuff.
Now on to actually testing Pd 0.56...
Wolfgang
Am 19. Jänner 2026 16:50:24 MEZ schrieb Wolfgang Gaggl wgaggl1@gmail.com:
I finally found the issue that crashed the GUI of Pd 0.56.2 on Irix 6.5.22!
hooray!!!
It was the pd.gif icon. Icons in Irix are .xpm files. This should be a configure update.
so you have any specific suggestion (that doesn't add too much cruft to the build system?)
IOhannes, if the gif icon works on the Mame emulator, it's because it's patched with Nekoware stuff.
that's very likely. I'm not really experienced with IRIX...
mfg.sfg.jfd IOhannes
On 1/20/26 00:14, IOhannes m zmölnig via Pd-list wrote:
Am 19. Jänner 2026 16:50:24 MEZ schrieb Wolfgang Gaggl wgaggl1@gmail.com:
I finally found the issue that crashed the GUI of Pd 0.56.2 on Irix 6.5.22!
hooray!!!
It was the pd.gif icon. Icons in Irix are .xpm files. This should be a configure update.
so you have any specific suggestion (that doesn't add too much cruft to the build system?)
so would it be as simple as fixing the code in pd-gui.tcl like this:
set icon [file join $::sys_guidir pd.gif]
if { $::tcl_platform(os) eq "IRIX"} {
set icon [file join $::sys_guidir pd.xpm]
}
(and probably add pd.xpm to the list of files to be installed alongside pd.gif)
I was just thinking... do we have an XPM? I remember tweaking one by hand when I updated the icon, so there *should* be one.
Also, is there maybe another check to see if GIF compatibility is there instead of the platform check? Just a thought.
Dan Wilcox danomatika.com robotcowboy.com
On Jan 20, 2026, at 10:11 AM, IOhannes m zmoelnig via Pd-list pd-list@lists.iem.at wrote:
On 1/20/26 00:14, IOhannes m zmölnig via Pd-list wrote:
Am 19. Jänner 2026 16:50:24 MEZ schrieb Wolfgang Gaggl wgaggl1@gmail.com:
I finally found the issue that crashed the GUI of Pd 0.56.2 on Irix 6.5.22!
hooray!!!
It was the pd.gif icon. Icons in Irix are .xpm files. This should be a configure update.
so you have any specific suggestion (that doesn't add too much cruft to the build system?)
so would it be as simple as fixing the code in pd-gui.tcl like this:
set icon [file join $::sys_guidir pd.gif] if { $::tcl_platform(os) eq "IRIX"} { set icon [file join $::sys_guidir pd.xpm] }(and probably add pd.xpm to the list of files to be installed alongside pd.gif)
-- please do not CC me for list-emails
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/W57B2E2L6L...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/ <OpenPGP_signature.asc>
On 1/20/26 12:18, Dan Wilcox wrote:
I was just thinking... do we have an XPM? I remember tweaking one by hand when I updated the icon, so there *should* be one.
yes, it's still there (just not installed).
Also, is there maybe another check to see if GIF compatibility is there instead of the platform check? Just a thought.
indeed, that would be the better solution.
as a sidenote, i couldn't even load the xpm within TclTk, not to speak of setting it as an icon. but i think we could simply not try to set any icon, if we can detect that GIFs are not supported. (as in: those niche platforms can probably live without).
maybe wolfgang can shed some more light on what he actually had to do.
gfasmdr IOhannes
I think it would be fine to use a switch in the pd-gui.tcl script to chose xpm with IRIX/SGI in the platform init procedure, which is what I did (just replacing gif with xpm in the script). We already install 3 flavors of Pd icons (gif, ico, xpm) with this distribution, and IRIX natively uses xpm (which will not change anymore). Any updates that allow gif as WM icons would not be natively available on IRIX, and it seems too restrictive to expect the user to patch their system for this. Given that xpm is expected as the native format by the window manager, I am not aware of an image format check for this on Irix. If you think this is too much hassle or not generalized enough I can look for a better solution (IRIX has tools to convert image formats, I'm just not sure without checking what comes with the plain vanilla system installation).
Thanks, Wolfgang
On 1/20/26 17:23, Wolfgang Gaggl wrote:
I think it would be fine to use a switch in the pd-gui.tcl script to chose xpm with IRIX/SGI in the platform init procedure, which is what I did (just replacing gif with xpm in the script). We already install 3 flavors of Pd icons (gif, ico, xpm) with this distribution, and IRIX natively uses xpm (which will not change anymore). Any updates that allow gif as WM icons would not be natively available on IRIX, and it seems too restrictive to expect the user to patch their system for this. Given that xpm is expected as the native format by the window manager, I am not aware of an image format check for this on Irix. If you think this is too much hassle or not generalized enough I can look for a better solution (IRIX has tools to convert image formats, I'm just not sure without checking what comes with the plain vanilla system installation).
so you are saying that my suggested code change (in my email from today 10:11CET) does work for you?
because for me the "image create photo /path/to/pd.xpm" simply fails with
--------------------------------------------------------------------------------
(Tcl) UNHANDLED ERROR: couldn't recognize data in image file
".../pd-0.56-2-24-gf30a183a/tcl/pd.xpm"
while executing
"image create photo -file $icon"
("uplevel" body line 1)
invoked from within
"uplevel #0 ${tclentry}"
so i guess the question is:
an icon)? (aka can we get a non-fatal error from that?)
i find it easiest to run tests with the tclprompt-plugin (go to "Find externals" and search for "tclprompt-plugin"; install it and restart Pd). this should give you a prompt line in the main Pd window where you can run Tcl/Tk commands interactively.
mfdasr IOhannes
I just checked, the icon file is not used by the application (in any format). So I opened up a wish command line/window and sent those commands. A bit surprising:
I don't know enough about tcl, but I don't see how to solve that issue right now. At this point we may just skip the icon all together for Irix.
Thanks, Wolfgang
On 1/21/26 01:27, Wolfgang Gaggl wrote:
At this point we may just skip the icon all together for Irix.
probably you are right.
another thing:
looking at the screenshot of your system, I noticed that I got a couple of assumptions wrong about your system. e.g. I happily assumed that your system would be somewhat compatible with the old SGI binaries from the beginning of the millenium. iirc, back then we supported "Irix5" (I'm assuming that this was an IRIX-5.x OS) running on o32 mode, and "Irix6" (I guess IRIX-6.x) running in n32 mode. i figure that both were 32-bit systems.
now afaict, your system is still an IRIX-6.x, but it's really a 64-bit system, so most likely uses the n64 abi. is this correct?
i guess that this should be reflected in the deken architecture. i told you to use "Irix6" and "mips" for deken-os and deken-cpu, but now I think that this is wrong. I guess the proper values should be "Irix" (OS) and "mips64" (CPU) or even "mipsn64".
maybe somebody can explain to me how the o32, n32, o64 and n64 ABIs relate to the various OS versions and processors (and then there's all the bi-endianness as well; but i guess IRIX always used big-endian, and little-endian systems usually use the "el" suffix). and which ABI could run on which processor, machine and OS version. e.g. I guess that an "IRIX64" system can run n64 binaries, most likely o64 binaries (is anybody using this?), but maybe also n32 and o32 binaries. "IRIX 6.x" can run n32 and o32 binaries (but probably not the 64bit ABIs). "IRIX 5.x" can run o32 binaries (but not n32). (of course, you cannot use different ABIs in the same process)
anyhow, it would be great if you (or really, anybody who still has access to SGI hardware), could run a few tests for me, to see how the various systems can be discovered. esp. i'm interested in
uname (with as much the information you can get)
like uname -apRsysconfgcc -dumpmachine (or similar, depending on thecompiler you are using)
cpp -dM /dev/null)array get tcl_platform (you obviouslyhave to run this within "tclsh" resp. "wish" - ideally the Tcl/Tk version that runs Pd)
mgfadsr IOhannes
The Octane is (and always was) a 64bit system (native o64, with n32 supported). If you ran this on an SGI O2, it would come up as 32bit (but same MIPS4 CPU family), with n32 only. The "n32" datatype is really a "compatibility type" to efficiently run 32bit apps on that 64bit CPU. The "o32" is what the older MIPS I and MIPS II 32bit CPUs (e.g. R2000) would natively run, they would not be able to run n32. Starting with MIPS III the CPUs were 64bit and supported n32, but not all of them would do 64bit (the native o64 type) based on their hardware architecture and IRIX kernel flavor (those would not be IRIX64). I'm not aware of a "n64" ABI type for SGI Irix, this sounds more like the NEC VR300i CPU (afaik not used in SGI workstations).
In the past (that means up to Pd0.40) I have forced Pd installs to n32 (what pd_irix6 used) and that's also what the configure script defaulted to for Pd0.56 (so I left it at that). I can gladly re-visit the 64bit ABI, since Pd can do that now, hopefully I don't run into any dependencies that only support n32. Not sure if that buy any extra performance (actually it might be opposite for some operations).
Will get you more of the requested info later.
Wolfgang
On 1/21/26 20:17, Wolfgang Gaggl wrote:
The Octane is (and always was) a 64bit system (native o64, with n32 supported). If you ran this on an SGI O2, it would come up as 32bit (but same MIPS4 CPU family), with n32 only. The "n32" datatype is really a "compatibility type" to efficiently run 32bit apps on that 64bit CPU. The "o32" is what the older MIPS I and MIPS II 32bit CPUs (e.g. R2000) would natively run, they would not be able to run n32. Starting with MIPS III the CPUs were 64bit and supported n32, but not all of them would do 64bit (the native o64 type) based on their hardware architecture and IRIX kernel flavor (those would not be IRIX64). I'm not aware of a "n64" ABI type for SGI Irix, this sounds more like the NEC VR300i CPU (afaik not used in SGI workstations).
thanks for the explanation.
the reason why i came up with "n64" was pages like https://wiki.debian.org/MipsRev6 (which does not speak of "o64")
also, according to man gcc (1), there are at least four different ABI-flags for MIPS. i used these flags on a local cross-compiler (on Debian), and they created different ABI-specific preprocessor defines:
| compiler flag | preprocessor define | |---------------|---------------------| | -mabi=32 | _ABIO32 | -mabi=n32 | _ABIN32 | -mabi=o64 | _ABIO64 | -mabi=64 | _ABI64
this is of course just general information about MIPS architectures and not specific to SGI/IRIX (that is: it might well be about machines that are decidedly *not* SGI/IRIX).
and I'm not exactly sure what the difference between -mabi=64 and -mabi=o64 actually is
anhow: so what do you think would be good architecture specifiers for OS and CPU?
the pair of the two must unanimously identify the architecture of a library that can be dlopen()ed (and used) by a given host binary.
Ideally the CPUs should use the same identifiers across operating systems (and this is why I write so long emails about ABIs)
I would suggest to use | OS | CPU | note |------|---------|------- | Irix | mips | o32 | Irix | mipsn32 | n32 | Irix | mips64 | o64
And for the ominous n64 architecture (if it actually exists) it would be Irix-mipsn64 (or Linux-mipsn64).
what do you think?
dasmr IOhannes
Consulting "man cc" on my Irix 6.5 (which calls the MIPSpro 7.4 compiler) I have listed the compiler flags for ABI below:
| OS | CPU | cflags |------|---------|------ | Irix | mips | o32 (same as 32) | Irix | mipsn32 | n32 | Irix | mips64 | 64 (native 64)
I compiled the good old whetstone.c for all of those above, including "o64" which wasn't even listed in man cc but just did the same as "64".
Your CPU column is a bit confusing, given that there really is a mips32 and mips64 platform now which are not the CPUs in SGI workstations, they are really IP cores used in modern SoC applications. The link you provided to MIPS32/64rev6 appears to be applicable to those newer post-SGI MIPS CPUs.
Note that when specifying -n32, the MIPSpro compiler will default to a mips4 CPU (both mips3 and mips4 can do n32), when specifying -o32 (or just -32) it will default to the mips2 CPU type (both mips1 and mips2 can do o32). For reference list of MIPS CPUs here: https://en.wikipedia.org/wiki/List_of_MIPS_architecture_processors
I guess I need to think about this a bit more.
Wolfgang