Building PiDP-8 software fails compiling code8.c

[StarNamer]

I bought a kit about 5 years ago, but never found time to put it together. I retired recently, so decided to start on it, beginning with building the software, but can't get it to compile.

I've tried both recipes 1 & 3 from the Quick Install page and the script from https://tangentsoft.com/pidp8i/wiki?name=Build+Setup and they all fail in a similar way, complaining of too many arguments to various function calls.

I've attached a zipfile of the log from using the TangentSoft script and hope someone would be kind enough to tell me what's wrong with my setup.

Thanks

Derek.

[Derek Dongray]

That's the version I tried which produced the log. It's the same link that I put in my last email.

On Sun, 26 Jul 2026 at 23:22, Mike Katz <justme...@gmail.com> wrote:

Try using this link:  PiDP-8 Latest Build.

This script will take care of all of the housekeeping you need to load the latest PiDP-8/I code for Bookworm or Trixie.

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-8/80b3afb4-95df-48be-b868-0c5e80437173n%40googlegroups.com.

--

Derek.

[Derek Dongray]

I didn't check the log in detail but made sure it had the compiler messages before attaching it.

I'm using a Pi 3B+ running Trixie, but it updates from the testing branch and was previously used for an electronics project - it's still connected to a breadboard though there's nothing on it.

My simplest solution is probably to get a fresh image as I suspect the issue is a changed default, possibly from using a 'testing' version.

Thanks.

On Mon, 27 Jul 2026 at 00:56, Mike Katz <justme...@gmail.com> wrote:

Sorry about that.

I looked at your log file and I see what you are talking about. 

I am in the middle of another project right now so i'm going to pass this along to Bill for now.

--

Derek.

[Derek Dongray]

Found the problem. It's a change to GCC which has an undesirable side-effect described here - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118112

Basically, when a function signature specifies no arguments (eg, int foo();), GCC-14 by default enforces the gnu17 standard, which allows calling this function with any number of arguments, whereas GCC-15 by default enforces the gnu23 standard, which only allows calling this function with zero arguments.

Since I've been updating from the 'testing' branch, I've upgraded to GCC-15 so the C standard has changed. Apparently the workaround is to add -std=gnu17 to CC8_CROSS_CFLAGS seems to work apart from a few ownership and permission errors. 

--

Derek.

[William Cattey]

Hello Derek,

Sorry for the delay in reviewing your problem.  

I think root cause is that you're using a different C compiler than we have been.

You can run cc --version and confirm this.

You can edit Makefile.in to change:

CC8_CROSS_CFLAGS = -w @BUILDMODE@

to:

CC8_CROSS_CFLAGS = -w -std=c17 @BUILDMODE@

And rebuld. That may get you going. Meanwhile, I have an ANSI update to enqueue.

-Bill

Detail:

My version:

pidp8i@pidp8i:~/pidp8i$ cc --version
cc (Debian 14.2.0-19) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Asking claude.ai for help it says:

That error message is the signature of GCC 15 (or later) compiling in its new default C23 mode, not GCC 14.

In C17 and earlier, an empty () prototype means "this function takes an unspecified number of arguments" — it's essentially a non-prototype, and the compiler won't complain no matter how many arguments you pass. That's why your build with GCC 14.2.0 (which defaults to gnu17) is silent.

C23 changed this rule to match C++: foo() now means "takes zero arguments," exactly like foo(void). So under C23 semantics, void output_string(); really does declare a zero-argument function, and calling it with a string literal becomes a genuine prototype violation — which is exactly the "expected 0, have 1" error he's getting.

GCC 15 switched its default standard from gnu17 to gnu23, so if he installed a newer GCC (15.x), he'd get this behavior automatically even with the identical command line you're using.

Quick fix on his end: add -std=gnu17 (or -std=c17) to the command line to restore old-style semantics.

Real fix for your codebase: update the stale prototypes in extern.h to proper ANSI prototypes, e.g. void output_string(char *); (or void output_string(void); if it truly takes none) — that make the code portable across old and new compilers instead of relying on the K&R "no prototype" loophole.

[William Cattey]

I see that I researched your question while your reply with your own discovery of the problem and the fix came in.

Carry on!

-Bill

[StarNamer]

Just for completeness...

derek@pi3b:~ $ cc --version
cc (Debian 15.3.0-1) 15.3.0
Copyright (C) 2025 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I haven't done extensive testing but the pidp8 service seems to work fine. So now I just need to build the kit. :)