Missing stdbool.h When Making dahdi-linux With Kernel 5.14 (Centos 19 Stream)

After running into problems with make install of Asterisk, I decided to clean-up my machine and start the installation process. (This is a home hobby project.)

Current configuration of the box:
Operating System: CentOS Stream 9
Kernel: Linux 5.14.0-85.el9.x86_64
Architecture: x86-64

The installed card:
03:00.0 Network controller: Digium, Inc. Wildcard A8B 8-port analog card (PCI-Express) (rev 01)

The instructions I used to get the latest version of dahdi-linux are here:

https://community.asterisk.org/t/dahdi-fails-fatal-error-linux-pci-aspm-h-no-such-file-or-directory/83561

It talks about a problem and solution for a missing #include <linux/pci-aspm.h> which is sort of the problem I am having now but with stdbool.h:

CC [M] /usr/local/src/dahdi-linux/drivers/dahdi/wct4xxp/base.o
/usr/local/src/dahdi-linux/drivers/dahdi/wct4xxp/base.c:45:10: fatal error: stdbool.h: No such file or directory
45 | #include <stdbool.h>
| ^~~~~~~~~~~
compilation terminated.

Someone had a similar problem using Debian:

https://groups.google.com/g/linux.debian.bugs.dist/c/NQP3JCZN3qc

And provided a patch file.

Aside from not being sure how to apply the patch, I am a bit leery as it is not from a Asterisk server.

Is there a planned fix for the dahdi/kernel 5.14 problem that might be available from git://git.asterisk.org/dahdi/linux?

Does the patch seem resaonable? If so, how is it applied?

Thank you!

Don

the patch look fine
if is only a replace

#include <stdbool.h>

with

#include <linux/types.h>

I took the dive and ran the patch, and it appears to have successfully addressed the stdbool.h problem. However, while the install got past that problem, it has exposed another problem:

[me@localhost dahdi-linux]# make install
make -C drivers/dahdi/firmware firmware-loaders
make[1]: Entering directory '/usr/local/src/dahdi-linux/drivers/dahdi/firmware'
make[1]: Leaving directory '/usr/local/src/dahdi-linux/drivers/dahdi/firmware'
make -C /lib/modules/5.14.0-85.el9.x86_64/build M=/usr/local/src/dahdi-linux/drivers/dahdi DAHDI_INCLUDE=/usr/local/src/dahdi-linux/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[1]: Entering directory '/usr/src/kernels/5.14.0-85.el9.x86_64'
  CC [M]  /usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.o
/usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.c: In function ‘xbus_read_proc_open’:
/usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.c:1842:50: error: implicit declaration of function ‘PDE_DATA’; did you mean ‘NODE_DATA’? [-Werror=implicit-function-declaration]
 1842 |         return single_open(file, xbus_proc_show, PDE_DATA(inode));
      |                                                  ^~~~~~~~
      |                                                  NODE_DATA
/usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.c:1842:50: warning: passing argument 3 of ‘single_open’ makes pointer from integer without a cast [-Wint-conversion]
 1842 |         return single_open(file, xbus_proc_show, PDE_DATA(inode));
      |                                                  ^~~~~~~~~~~~~~~
      |                                                  |
      |                                                  int
In file included from /usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.c:29:
./include/linux/seq_file.h:150:68: note: expected ‘void *’ but argument is of type ‘int’
  150 | int single_open(struct file *, int (*)(struct seq_file *, void *), void *);
      |                                                                    ^~~~~~
/usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.c: In function ‘proc_xbus_command_open’:
/usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.c:1949:28: warning: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
 1949 |         file->private_data = PDE_DATA(inode);
      |                            ^
/usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.c: In function ‘xpp_proc_read_open’:
/usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.c:1992:54: warning: passing argument 3 of ‘single_open’ makes pointer from integer without a cast [-Wint-conversion]
 1992 |         return single_open(file, xpp_proc_read_show, PDE_DATA(inode));
      |                                                      ^~~~~~~~~~~~~~~
      |                                                      |
      |                                                      int
In file included from /usr/local/src/dahdi-linux/drivers/dahdi/xpp/xbus-core.c:29:
./include/linux/seq_file.h:150:68: note: expected ‘void *’ but argument is of type ‘int’
  150 | int single_open(struct file *, int (*)(struct seq_file *, void *), void *);
      |                                                                    ^~~~~~
cc1: some warnings being treated as errors

It appears to be a type mismatch problem as a result of other recent changes in the kernel. When I get a chance, I am going to see if I can unravel the mismatch between xbus-core.c and /include/linux/seq_file.h If anyone has any suggestions as how to proceed, I would greatly appreciate them!

Given the linux/pci-aspm.h fix is in the “next” branch of dahdi, the stdbool.h problem has been identified, but not apparently in the next branch, and now apparently other kernel related problems, is there any dahdi activity trying to keep up with the kernel updates? Getting locked into an old kernel can open up security issues as kernel updates address vulnerabilities.

Thank you!

Don

Okay, found that PDE_DATA() has been renamed pde_data():

https://github.com/openzfs/zfs/issues/13004

After that I managed to get everything thru make. However, something is still amiss:

May 09 19:56:33 localhost.localdomain dahdi[40107]: /etc/rc.d/init.d/dahdi: line 64: /etc/init.d/functions: No such file or directory
May 09 19:56:33 localhost.localdomain systemd[1]: dahdi.service: Control process exited, code=exited, status=1/FAILURE

While the make process seems to create the dahdi service, the "functions" file appears to be missing.  I am assuming the dahdi make and configure process should create that file.  Is this correct?

When I get some additional time I will try to debig this problem.

Turns out my Centos install did not have the initscripts package installed:

[me@localhost dahdi-tools]# dnf install initscripts
Last metadata expiration check: 0:07:30 ago on Tue 10 May 2022 08:53:00 AM EDT.
Dependencies resolved.
=========================================================================================================================================================================
 Package                                   Architecture                         Version                                       Repository                            Size
=========================================================================================================================================================================
Installing:
 initscripts                               x86_64                               10.11.4-1.el9                                 baseos                               232 k
Installing dependencies:
 chkconfig                                 x86_64                               1.20-2.el9                                    baseos                               180 k

Transaction Summary
=========================================================================================================================================================================
Install  2 Packages

Still have some lingering issues, but suspect it might be due to performing the make for dahdi-linux and dahdi-tools without the package(s). Will re-make, and reboot for good measure, and report back.

Have all the compile problems out of the way (I think!). However, system.conf and assigned-spans.conf in /etc/dahi do not appear to be generated. This looks like a problem described in:
https://community.asterisk.org/t/dahdi-installing-problem/65983/37

Going to start a new thread with a more appropriate title to see if it gets attention.

or get an admin to change the title for you

Never a good idea; it fragments the background information.

As far as I know there is only one person actively answering who has any dahdi knowledge, the one who created the pulse dial modifications, and even having him there is unusual. Also, generally the people who answer monitor all threads. Traditionally, the advice for dahdi was to get support from your hardware card supplier.

Changing the subject would be more reasonable.

TheMark, david551 – Regarding opening a thread.
I struggled with the decision, but given that the original problem was effectively solved it seemed more reasonable to break out the new problem. That way anyone experiencing the kernel build problem would have one thread and those with config problems another.

david551 - Given all the info on the asterisk.org site, I assumed it’s repository for dahdi was the repository. Looking at
https://wiki.freepbx.org/display/PC/Telephony+Cards+for+Asterisk
it looks like they have a tool called for Wanpipe, so looking at that now. Will add this info to the other thread.

Thank you for your comments!

Don

Wanpipe was a third party product, before Digium was taken over by Sangoma. Historically, that would have definitely resulted in being referred to the card vendor.

Looking at the Wanpipe online documentation, it appears it assumes dahdi and asterisk are already installed. And, to me, that implies that the conf files should be there. And that leads back to

https://community.asterisk.org/t/configuring-dahdi-does-not-create-system-conf-in-etc-dahdi/92626