Asterisk 1.8.3.2 make fails at res_adsi

Not sure if the res_adsi is needed for the system to perform correctly, however I used the make progdocs after unselecting the make menselect Application -> app_adsiprog then Resource Modules -> res_adsi.
I have tried this on a P4 3.00ghz and the HP DL320 server, both fail at the res_adsi same line of code 362.

According to the progdocs this looks to be an integral part of several applications one of which is voicemail, it specifically states that it was introduced due to message problems going to voicemail. If it has been superceded then I will forward and note the application.

The basics:
CentOS 5.6 installed on a SATA RAID 1 HP server
Linux asterisk.sip_kmtnetworks.com 2.6.18-238.9.1.el5 #1 SMP Tue Apr 12 18:10:56 EDT 2011 i686 i686 i386 GNU/Linux

Package prerequisites per the Asterisk Docs
OPenSSL
ncurses
newt
libxml2
Kernel headers(for building DAHDI drivers)

openssl-0.9.8e-12.el5_5.7
openssl-devel-0.9.8e-12.el5_5.7
ncurses-5.5-24.20060715
ncurses-devel-5.5-24.20060715
newt-0.52.2-15.el5
newt-devel-0.52.2-15.el5
newt-perl-1.08-9.2.2
ibxml2-2.6.26-2.1.2.8.el5_5.1
libxml2-devel-2.6.26-2.1.2.8.el5_5.1
libxml2-python-2.6.26-2.1.2.8.el5_5.1

LibPRI 1.4.11.5
DAHDI 2.4.2.1

Keep in mind this failed on two different servers with two clean hdd units, nothing else running no vmware, nothing, repartitioned the hdd units and started from scratch. Used the default packages and they were installed and verified before I upgraded/installed any new ones.

Actions:
Installed gcc 4.6.0 manually rpm does not see the new gcc loaded, it still reports 4.1.2
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.6.0 (GCC)

Upgraded ncurses to 5.9 manually using the gnu.org link to find ncurses, so rpm -q will not show the update.

I used vim and the progdocs to review the res_adsi.c file, line code 362
Sorry for the partial code on line 362 got caught bewteen builds, however anyone can use vim res_adsi.c and go to line 362 or use the progdocs. line 362 is just { and thats it, which looks to be some either a code problem or a library problem.

Install is performed from root, /Asterisk/asterisk-1.8.3.2
./configure
make menuselect
make The only to get make to finish is to unselect app_adsiprog and res_adsi
make install
make samples
make progdocs
make config

Then
make clean
make distclean

As I knew I would be doing this again, yes removed and downloaded the tarball again.

Error as seen from the cli, this is a standard tarball configuration and setup


(.text+0x36d0): multiple definition of ast_adsi_voice_mode' ../res/res_adsi.o:/Asterisk/asterisk-1.8.3.2/res/res_adsi.c:770: first defined here ../res/res_adsi.eo: In functionast_adsi_clear_soft_keys’:
(.text+0x3690): multiple definition of ast_adsi_clear_soft_keys' ../res/res_adsi.o:/Asterisk/asterisk-1.8.3.2/res/res_adsi.c:731: first defined here ../res/res_adsi.eo: In functionast_adsi_available’:
(.text+0x36f0): multiple definition of ast_adsi_available' ../res/res_adsi.o:/Asterisk/asterisk-1.8.3.2/res/res_adsi.c:782: first defined here ../res/res_adsi.eo: In functionast_adsi_connect_session’:
(.text+0x2cc0): multiple definition of ast_adsi_connect_session' ../res/res_adsi.o:/Asterisk/asterisk-1.8.3.2/res/res_adsi.c:490: first defined here ../res/res_adsi.eo: In functionast_adsi_transmit_message_full’:
(.text+0x25b0): multiple definition of `ast_adsi_transmit_message_full’
…/res/res_adsi.o:/Asterisk/asterisk-1.8.3.2/res/res_adsi.c:362: first defined here
collect2: ld returned 1 exit status
make[1]: *** [asterisk] Error 1
make: *** [main] Error 2
[root@asterisk asterisk-1.8.3.2]#

00361 int AST_OPTIONAL_API_NAME(ast_adsi_transmit_message_full)(struct ast_channel *chan, unsigned char *msg, int msglen, int msgtype, int dowait)
00362 {

Any assitance is very much appreciated, I cannot find aything for this line code, the only fix I have seen is for the ncurses library to be loaded on a server that had the problem, which is why I upgraded the ncurses to 5.9. Unfortunatley the other fixes involve unselecting the res_adsi, but this is a lab certification process and I have to investigate all causes and reasons. TrixBox, AsteriskNow will suffice for this process.

Cant say enough about the progdocs wonderful to have, cudos to those guys, all this great.
I see a lot of class 5 carrier grade products too, code and interactions between system is why we need good people. If someone complains oh well, I see class 5 and class 3 systems all the time with hundreds of patches loaded on them.

So rolling back to an earlier version of ncurses, e.g. 5.5, doesn’t present the problem?

ncurses versions reported by rpm before I performed the manual install of 5.9
original version installed with CentOS
ncurses-5.5-24.20060715
ncurses-devel-5.5-24.20060715

ncurses version has no effect so far, I guess I could try an older version say around
I will be stripping the lab server back to partitioning and then re-installing CentOS 5.6, custom install, however this will the 6th time for the re-install all with different versions, this time I will not be changing any versions after the initial install of CentOS, a simple blank DNS and no GW IP will suffice, then kill the yum update service so no updates can be done.

I will also be using Debian as well, I actually prefer it over CentOS, but Asterisk docs state CentOs is preferred.

I was trying to if anyone here is installing their system from the tarball and what kind of problems they had with res_adsi.

I started withe Astersik 1.8.2.2, then 1.8.2.4, now oon 1.8.3.2, all within one month of starting this eval, buggy but hey, its worth the time. So far the 1.8.2.2 and .2.4 all had the same res_adsi problem, now I have an additional problem, since 1.8.3.2 the system now does not see the astdb file in the /var/lib/asterisk directory, reason is, it is not there at all. All on the same CentOS 5.6 load/reload on the same two servers.

Guess I’ll wait for the next 1.8.x.x to be distributed.

Thanks for the input,