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:
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.
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.
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.
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.
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.
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