I am unable to load app_meetme.so and app_page.so. When I try and load from CLI I get:
Module ‘app-page.so’ was not compiled with the same compile-time options as this version of Asterisk.
And it refuses to load either app. I compiled from source as follows
cd /usr/src/asterisk
cd dahdi-linux-complete-2.6.1+2.6.1
sudo make
sudo make install
sudo make config
cd ..
cd asterisk-1.8.18.1
cd menuselect
sudo make clean
sudo ./configure
cd ..
sudo ./configure
sudo make
sudo make menuselect
- Applications: app_meetme, app_page are checked
sudo make
sudo make install
Is ‘make’ screwed forever? I ran a ‘make’ again after ‘make menuselect’ even though there was a ‘make’ before. In fact, I did that because in the manual I followed, he had me install, then go back and use menuselect to add sounds - that’s why I showed the first one.
I have run ‘make’ and then ‘make install’ again but still same problem.
I have never needed to do anything in the menuconfig sub-directory.
It is possible that a late make menuselect will work, but if it does, you will compile everything twice, the second time definitely as root.
Whilst I’m not really sure what is happening, o be on the safe side, I would:
Start from a clean tarball.
Stop Asterisk before the make install.
Also stop dahdi.
Remove /usr/sbin/asterisk and the contents of /usr/lib/asterisk/modules.
Do the make install, and subsequent steps. in particular, make configs.
Start dahdi.
Start Asterisk.
I notice that you are still doing the make twice, but now explicitly. I believe that the build system should invalidate all build products after the make menuconfig, but you would probably get your symptom if it missed somethings and only did a partial rebuild.
Compiling from source is not one of my best abilities, I have to admit. But I played with menuselect. I removed meetme and page and redid the make. When make removed the options it warned me that the 2 .so files were not from the same build. I added them back and ‘make’ happily built them in not caring that they were possibly incompatible. ‘make install’ still had the problem and the modules could not be loaded.
I had installed each dependency individually myself so I tried ‘install_prereq install’ in the contrib/scripts but that was a disaster. It came up with line after line of something open something closed and failed after a very long with an out of memory error.
At this point I was f’n p’sd-off I did a ‘make uninstall’ on asterisk and dahdi. And found out dahdi doesn’t uninstall (didn’t help my mood). I dumped a find into a file and used it and xargs to wipe it out - not very nice at all. I used dahdi 2.6.0+2.6.0 from downloads.asterisk.org so I tried going back to 2.4.0 and 2.5.something but they refused to compile claiming they had trouble with a file linux/something.h so wound up sticking with 2.6.0
I then did 'make clean" on dahdi and asterisk. While I don’t need anything in libpri, it seems tightly related to dahdi which I do need. Contrary to the O’Riley’s book, dahdi has to be compiled first or libpri fails. Even still it generates an error. I don’t recall the message but I think there was a bug notice on it; something about stopping a loop that causes a write fail - but doesn’t seem fatal in my case because I don’t need it.
I also noted some not some exceptions while dahdi compiled but no fails. Ditto on asterisk so I am expecting something to bite me down the road. However, I do have Page and MeetMe.
Using Page() is complains: No channel type registered for 'DAHDI’
I have not been able to find anything useful for helping me resolve this so far.
I have setup several Linux servers in the past few years with SAMBA, MySQL/php, Apache, SMTP, NFS mirrors etc. and while they all had their quirks they were very solid installations in that any problems were consistent and easy to reproduce and the fixes were understandable and performed predictably. Asterisk has been my worst experience on Linux so far: it’s tempermental and even after documenting all of the support software I installed for it I still don’t understand the dependencies or the sequence to get solid installation working.
If Page can’t find dahdi, it either means that you didn’t load the dahdi kernela modules before starting asterisk, or you have a fatal error in chan_dahdi.conf.
Normally, for Redhat, or CentOS, the service start script for dahdi is part of dahdi-linux-tools and installed by installing it (I’m not sure if complete includes tools). The service script for asterisk is loaded by make configs.
You don’t need libpri if you are only using dahdi for its software conference bridge, and for timing.