FreePBX | Register | Issues | Wiki | Portal | Support

Questions about building Asterisk 13.22.0


(Herb Weiner) #1

I am running FreePBX 14.0.11 with Asterisk 13.22.0.

I downloaded the Asterisk 13.22.0 source to my freepbx system, installed jansson-2.12 (./configure; make; make install), made a few changes to main/pbx.c to add a few ast_log messages, to better understand the behavior of my system, and built Asterisk (./bootstrap.sh; ./configure; make). I did NOT do a make install, because I am not ready to replace my running system.

I have a two questions:

  • The new asterisk that I’ve built is almost four times larger (15366832 bytes vs. 4038152 bytes) than the asterisk that was installed with freepbx. Any theories as to what would cause such a significant discrepancy, or whether this is a cause for concern?
  • I temporarily replaced /usr/sbin/asterisk with my newly built asterisk, and restarted the system. I got about 75 Error loading module … undefined symbol messages, and my system would not accept any incoming calls. A small sample of these messages is listed below. I immediately restored the original asterisk and restarted the system, and all was back to normal. Any theories on what would cause these errors, and how to resolve them?

[2019-06-08 14:38:30] WARNING[6935] loader.c: Error loading module ‘cdr_adaptive_odbc.so’: /usr/lib64/asterisk/modules/cdr_adaptive_odbc.so: undefined symbol: ast_odbc_backslash_is_escape
[2019-06-08 14:38:30] WARNING[6935] loader.c: Error loading module ‘chan_pjsip.so’: /usr/lib64/asterisk/modules/chan_pjsip.so: undefined symbol: ast_sip_cli_traverse_objects
[2019-06-08 14:38:30] WARNING[6935] loader.c: Error loading module ‘res_pjsip.so’: /usr/lib64/asterisk/modules/res_pjsip.so: undefined symbol: pjsip_invite_method
[2019-06-08 14:38:30] WARNING[6935] loader.c: Error loading module ‘res_ari_events.so’: /usr/lib64/asterisk/modules/res_ari_events.so: undefined symbol: stasis_app_register_all
[2019-06-08 14:38:30] WARNING[6935] loader.c: Error loading module ‘res_monitor.so’: /usr/lib64/asterisk/modules/res_monitor.so: undefined symbol: __ast_beep_start


#2

To do that you would need to build asterisk with statically linked libraries and each of the libraries would themselves need to be already statically linked.

To put it lightly , this is NOT a trivial task.


(Herb Weiner) #3

Thanks, dicko. Are you suggesting that to avoid the errors I am experiencing, I must do a make install? Or are you suggesting that even doing a make install would not resolve these errors, and that if I want to rebuild asterisk, I have no choice but build using statically linked libraries?

Also, if the originally installed asterisk is statically linked, why is it smaller than the (presumably dynamically linked) version that I built? I would have assumed that the statically linked version would be larger.


#4

I am saying if you dont want to replace your libraries you will have to statically link everything (yes your asterisk will be huger than huge and almost certainly wont work until you spend a decade debugging it)

temporarily move them along with your asterisk binary, better yet do that in a virtualized environment where even the biggest effup is 10 minutes away from recovery :wink:


(Herb Weiner) #5

Thanks, dicko. I will try what you suggest, since I am not looking to make life more difficult than it already is.

However, I still don’t understand why the asterisk that was installed with freepbx is SMALLER than what I built myself.


#6

Ultimately the Makefile you created (bundled libraries , compile options, optimizations etc.) will define the size of the final binary, sangoma has so far been very reticent to share their Makefile so any answers would likely be conjecture.


(Herb Weiner) #7

Thanks, dicko. I had assumed that sangoma was building asterisk using the Makefile provided with asterisk. However, I can understand why they might want to customize their Makefile, and such customizations could clearly explain the differences I am seeing.


#8

There is no Makefile in the source code, it would defeat the purpose, think about it :wink:

There is a bunch of scripts in contrib that are useful and then ./configure, which looks at your system and your choices and (mostly) generates a Makefile that will work in conjunction with

make menuconfig && make

on your platform. If you competently edited pbx.c then there would be no problem with that method.


(M Wise) #9

Are you using the tar download from asterisk directly? You don’t want to do that and the result won’t really be compatible with the FreePBX Distro. If you build Asterisk from the SRPM, you can package a custom RPM you can install using yum.

You can set up a development environment on a FreePBX Distro install with (you probably want to set up a virtual machine to do this - don’t do this on your production machine):

yum -y install sangoma-devel

Then run this to grab the source RPM

yumdownloader --source asterisk13-13.22
rpm -i <asterisk13 rpm>
cd ~/rpmbuild/SOURCES

then you can extract and change, apply patches, etc. to the asterisk source tar from in there, retar the source if necessary then go into the ~/rpmbuild/SPECS directory and run

rpmbuild -ba asterisk13.spec

to compile asterisk and create a custom RPM that will be distro compatible, as the executable and shared libraries will be compiled in the same way as Sangoma does for the distro. I do this to create a custom version of chan_sip.so - the resulting shared library is a drop in replacement for the one in the regular asterisk RPM.


#10

One could hope that quite soon, as asterisk ‘id est’ sangoma, then any outstanding sangoma patches against asterisk main will be merged with main, then either of the above recipes should be identical in result.

Downloading srpms, extracting, , patching, recompiling, regenerating rpms then re deploying them? Perhaps pedantic but horribly slow and only works on a “distro”.

What about debian , raspberry, arch linux, arm routers?

Far from saying it is a bad solution, it just seems a very long winded way of doing the same things that should be elemental and cross platform yet is exclusive by it’s very nature.


(Herb Weiner) #11

Thank you for this suggestion, M Wise. I have been occupied with other projects for several days, I will give this a try.

I have now installed freepbx on a spare workstation. Is there any advantage to setting up a virtual machine, or would I do just as well running my experiments on a completely separate workstation?


(M Wise) #12

The virtual machine is just for convenience.