dwmblocks fails to build

[c0bra669]

After running sudo make install I got this error:

cc -o dwmblocks dwmblocks.c -pedantic -Wall -Wno-deprecated-declarations -Os -lX11
dwmblocks.c: In function ‘getcmd’:
dwmblocks.c:68:41: error: ‘delimLen’ undeclared (first use in this function); did you mean ‘delim’?
   68 |         fgets(tempstatus+i, CMDLENGTH-i-delimLen, cmdf);
      |                                         ^~~~~~~~
      |                                         delim
dwmblocks.c:68:41: note: each undeclared identifier is reported only once for each function it appears in
dwmblocks.c: In function ‘main’:
dwmblocks.c:197:51: error: ‘delimLen’ undeclared (first use in this function); did you mean ‘delim’?
  197 |                         strncpy(delim, argv[++i], delimLen);
      |                                                   ^~~~~~~~
      |                                                   delim
dwmblocks.c:207:25: error: passing argument 2 of ‘signal’ from incompatible pointer type [-Wincompatible-pointer-types]
  207 |         signal(SIGTERM, termhandler);
      |                         ^~~~~~~~~~~
      |                         |
      |                         void (*)(void)
In file included from dwmblocks.c:5:
/usr/include/signal.h:88:57: note: expected ‘__sighandler_t’ {aka ‘void (*)(int)’} but argument is of type ‘void (*)(void)’
   88 | extern __sighandler_t signal (int __sig, __sighandler_t __handler)
      |                                          ~~~~~~~~~~~~~~~^~~~~~~~~
dwmblocks.c:188:6: note: ‘termhandler’ declared here
  188 | void termhandler()
      |      ^~~~~~~~~~~
/usr/include/signal.h:72:16: note: ‘__sighandler_t’ declared here
   72 | typedef void (*__sighandler_t) (int);
      |                ^~~~~~~~~~~~~~
dwmblocks.c:208:24: error: passing argument 2 of ‘signal’ from incompatible pointer type [-Wincompatible-pointer-types]
  208 |         signal(SIGINT, termhandler);
      |                        ^~~~~~~~~~~
      |                        |
      |                        void (*)(void)
/usr/include/signal.h:88:57: note: expected ‘__sighandler_t’ {aka ‘void (*)(int)’} but argument is of type ‘void (*)(void)’
   88 | extern __sighandler_t signal (int __sig, __sighandler_t __handler)
      |                                          ~~~~~~~~~~~~~~~^~~~~~~~~
dwmblocks.c:188:6: note: ‘termhandler’ declared here
  188 | void termhandler()
      |      ^~~~~~~~~~~
/usr/include/signal.h:72:16: note: ‘__sighandler_t’ declared here
   72 | typedef void (*__sighandler_t) (int);
      |                ^~~~~~~~~~~~~~
dwmblocks.c: At top level:
dwmblocks.c:56:12: warning: ‘returnStatus’ defined but not used [-Wunused-variable]
   56 | static int returnStatus = 0;
      |            ^~~~~~~~~~~~
make: *** [Makefile:20: dwmblocks] Error 1

The @LukeSmithxyz build works so i'm pretty sure that i'm doing everything correctly

[beyond990]

I ran into the same issue and it is caused by the gcc 15, if you edit the Makefile and add
-std=gnu17 to the beginning of CFLAGS it will compile with a warning about the unused retrurnStatus. I have a fix for that but really is not needed.

[c0bra669]

I ran into the same issue and it is caused by the gcc 15, if you edit the Makefile and add -std=gnu17 to the beginning of CFLAGS it will compile with a warning about the unused retrurnStatus. I have a fix for that but really is not needed.

It works thank you

[D3epCr3ature]

I ran into the same issue and it is caused by the gcc 15, if you edit the Makefile and add -std=gnu17 to the beginning of CFLAGS it will compile with a warning about the unused retrurnStatus. I have a fix for that but really is not needed.

Or this, or adding the int to both prototype and declaration of the termhandler function, like:

void termhandler(int);

/* ... */

void termhandler(int)
{
        statusContinue = 0;
}

If the parameter will never be used, the 1st approach is better. But it adds a certain dependency on the compiler's version.
Whereas the second avoids that "issue". Both solutions are valid in their own way. 👍

As for my final thought, I think the second is better to get all possible optimizations of the latest compiler's version.