[Home]

Summary:ASTERISK-01791: [patch] Merged changes from FreeBSD Asterisk port
Reporter:rich (rich)Labels:
Date Opened:2004-06-10 00:16:08Date Closed:2008-01-15 15:00:09.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) BSD040622link.txt
( 1) BSD040622min.txt
( 2) BSD040622mutex.txt
( 3) BSDdifs2.txt
( 4) BSDdifs3.txt
( 5) freebsd-ports.dif.txt
Description:These are a portion of the remaining patches from the current FreeBSD Asterisk port.  It adds FreeBSD support ilbc and gsm codecs and partial support for h323.  I've tested it on FreeBSD 5.2.1 and Redhat 9.
Comments:By: Olle Johansson (oej) 2004-06-10 09:09:26

Seem to work fine on my FreeBSD 4.9 as well.
By: Mark Spencer (markster) 2004-06-10 15:00:55

This would appear to hard code some FreeBSD things in the H.323, is that correct?
By: rich (rich) 2004-06-10 15:56:48

Yep, they're hardcoded for the moment. For the moment the values are merely clues to what the variables mean.

The intention is to break out those values (directory paths to h323 and pwlib) into variables that can be configured by the FreeBSD ports.  They are currently supplied by patching the makefiles.  So it would be helpful to make them variables and perhaps surround them with some context such that the patches work across versions of asterisk, or perhas allow them to be set via environment variables.  

It should be possible to create a port of Asterisk current.  Maxim Sobalev would be supportive of it and it would accelerate the testing by lowering the bar for those wanting to install all the bells and whistles.

The 'ports' system also addresses variations in OS versions, and we've use that mechanism to determine which thread libraries to link.

We may be able to leverage much of this for Netbsd and others (trusted bsd, dragonfly bsd, etc.).  So, I'm trying to generalize some of the conditional statements to cover all *BSDs.  I really should be testing on OpenBSD and Netbsd, but from a practical standpoint I'm more concerned about effects on linux support.

So, if any of this should be done in a more conservative way, I'd be glad to follow your preferences!
By: Mark Spencer (markster) 2004-06-11 10:28:07

I'd like to go ahead and merge whatever we can now without hard coded values.  My goal is that there would eventually need to be no modifications for BSD.
By: Olle Johansson (oej) 2004-06-11 16:05:57

We need to add -L/usr/local/lib to find odbc libraries in res/Makefile
By: Olle Johansson (oej) 2004-06-11 16:09:41

Rich, this is needed on 4.9:
Index: res/res_odbc.c
===================================================================
RCS file: /usr/cvsroot/asterisk/res/res_odbc.c,v
retrieving revision 1.1
diff -u -r1.1 res_odbc.c
--- res/res_odbc.c      11 Jun 2004 00:12:35 -0000      1.1
+++ res/res_odbc.c      11 Jun 2004 20:53:25 -0000
@@ -281,8 +281,8 @@
}

odbc_status odbc_obj_disconnect(odbc_obj *obj) {
-  ast_mutex_lock(&obj->lock);
  int res;
+  ast_mutex_lock(&obj->lock);

  if(obj->up)
    res = SQLDisconnect(obj->con);
By: rich (rich) 2004-06-12 00:05:31

OK, thanks!  I'll put that change in,and remove the hard coded values.  I've got openbsd 3.5 installed as well, so I can test sip/iax2 there as well.  It should be possible to include <sys/param.h> and test for #ifdef BSD to cover all the *BSDs.  I can test that using FreeBSD and OpenBSD.  More tomorrow..
By: Olle Johansson (oej) 2004-06-12 04:33:23

Any FreeBSD user that have looked into the problem with pbxwilcalu?
By: rich (rich) 2004-06-12 07:09:58

Rich Neese may have looked at it..
By: Mark Spencer (markster) 2004-06-12 20:50:46

Do we have anything updated?
By: rich (rich) 2004-06-12 21:07:44

Yep, I'm testing on FreeBSD, Linux and OpenBSD.  I'll get it submitted in just a while.
By: rich (rich) 2004-06-12 23:12:45

BSDdifs.txt makes asterisk thread safe on OpenBSD.  It runs a regression test at startup, and if the locks are not recursive, prints a warning message, "Warning! Asterisk is not thread safe."   I've tested it on Redhat 9, FreeBSD 5.2.1 and OpenBSD 3.5.

We needed to a few more include files, some of which clashed with the use of 'MAX' as a symbol, so I've renamed those AST_MAX_WATCHERS.  Similarly, there was a 'MIN' renamed to MINUTES.

This should be easier to port to the remaining BSDs.  The hardcoded paths have been removed.

Cheers,
Rich
By: Olle Johansson (oej) 2004-06-13 15:30:47

Getting these errors compiling CVS head on 4.9:

gcc -g  -o asterisk -Wl,-E  io.o sched.o logger.o frame.o loader.o config.o channel.o translate.o file.o say.o pbx.o cli.o md5.o term.o ulaw.o alaw.o callerid.o fskmodem.o image.o app.o cdr.o tdd.o acl.o rtp.o manager.o asterisk.o ast_expr.o dsp.o chanvars.o indications.o autoservice.o db.o privacy.o astmm.o enum.o srv.o dns.o aescrypt.o aestab.o aeskey.o utils.o  editline/libedit.a db1-ast/libdb1.a stdtime/libtime.a -lc_r -lncurses -lm
/usr/lib/libc.so: WARNING!  setkey(3) not present in the system!
/usr/lib/libc.so: warning: this program uses gets(), which is unsafe.
/usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp()
/usr/lib/libc.so: WARNING!  des_setkey(3) not present in the system!
/usr/lib/libc.so: WARNING!  encrypt(3) not present in the system!
/usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp()
/usr/lib/libc.so: warning: this program uses f_prealloc(), which is not recommended.
/usr/lib/libc.so: WARNING!  des_cipher(3) not present in the system!
/usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp()
By: rich (rich) 2004-06-14 01:46:19

BSDdifs2.txt supercedes  BSDdifs.txt

On FreeBSD 4.9 there are some strange artifacts from the use of 'warm refrences' in libc.  It seems that any reference to one of these symbols will cause complaings about the whole set of 'warm referneces' in libc even if you don't use them.

If we actually used them we'd use '-lcrypt' to satisfy the references.  But as it stands they are harmless.  Perhaps we can come back and look at them later.

I added code to DEBUG_THREADS that complains about uninitialized mutexes, and found a few that werent' bein initialized early enough on FreeBSD, and fixed them.

I tested it with and without debug threads on Redhat 9, FreeBSD 5.2.1, FreeBSD 4.9 and OpenBSD 3.5.

Cheers,
Rich
By: Olle Johansson (oej) 2004-06-14 02:21:19

Great. I'll migrate to 4.10 on the system now.
By: rich (rich) 2004-06-14 21:59:19

BSDdifs3.txt supercedes BSDdifs2.txt

I've read through all the locks and esp. the initialization.  I wrote more diagnostics to detect uninitialized locks, redundant initialization, and dead/livelock.  I caught a few more dynamically allocated locks that needed initializaiton.

The diagnostics report no further initializaion or deadlock errors occurring, so I'm more comfortable about the locking.
By: rich (rich) 2004-06-22 12:13:07

BSD040622.txt:

This supercedes prior patches submitted for
mutex initialization.

On Linux static mutexes are initialized
statically, as before, whereas on FreeBSD
they are initialized and destroyed using
constructors and destructors.

All other mutexes are initialized explicitly
at load_module(), allocation, or startup, and
destroyed on unload_module(), deallocation,
or shutdown.

At startup, run a regression test for
recursive mutexes and print a warning if the
application is not thread safe.

-DDEBUG_THREADS turns on diagnostic warning
messages in lock.h for uninitialized locks
and deadlock.

Change g++ to $(CXX) in order to use
alternate compilers for diagnostics.

Change
ifeq (${OSARCH},FreeBSD)
to
ifeq ($(findstring BSD,${OSARCH}),BSD)
for portions of Makefiles that are common to
BSD flavors.


BSD0406min.txt:

Workaround namespace class between system
headers and asterisk for the symbols MIN and
MAX.


BSD040622link.txt:

Use gnu make's LDFLAGS variable rather than
SOLINK so that the makefiles can integrate
with other build tools.

Plus changes to channels/Makefile for
chan_h323.
By: Mark Spencer (markster) 2004-06-22 13:32:16

It looks like there's a mistake in destroy_zt_pvt, should the last line be *pvt = NULL?

I can fix that if you confirm thats what you want.

Other than that all three look fine.  I'll wait for your confirmation and then apply them.
By: rich (rich) 2004-06-22 13:44:41

Yep, *pvt = NULL is intended to catch dereferences to a destroyed pvt.  A portion of the code had done that.
By: Mark Spencer (markster) 2004-06-22 13:57:33

Okay I merged the mutex patch and the "min" patch (with the modification of pvt=NULL being changed to *pvt=NULL).

The "link" patch causes Asterisk to no longer build on my Fedora 1 system, so I've omitted it.
By: Mark Spencer (markster) 2004-06-23 23:49:06

I guess just open a new bug if we need to do something about the link stuff.
By: Digium Subversion (svnbot) 2008-01-15 15:00:09.000-0600

Repository: asterisk
Revision: 3273

U   trunk/Makefile
U   trunk/agi/Makefile
U   trunk/apps/app_dial.c
U   trunk/apps/app_queue.c
U   trunk/apps/app_rpt.c
U   trunk/apps/app_voicemail.c
U   trunk/asterisk.c
U   trunk/astman/Makefile
U   trunk/channels/chan_agent.c
U   trunk/channels/chan_h323.c
U   trunk/channels/chan_iax.c
U   trunk/channels/chan_iax2.c
U   trunk/channels/chan_local.c
U   trunk/channels/chan_mgcp.c
U   trunk/channels/chan_sip.c
U   trunk/channels/chan_skinny.c
U   trunk/channels/chan_vpb.c
U   trunk/channels/chan_zap.c
U   trunk/channels/h323/INSTALL.openh323
U   trunk/channels/h323/Makefile
U   trunk/cli.c
U   trunk/codecs/gsm/Makefile
U   trunk/codecs/lpc10/Makefile
U   trunk/include/asterisk/lock.h
U   trunk/include/asterisk/utils.h
U   trunk/include/asterisk/vmodem.h
U   trunk/manager.c
U   trunk/pbx.c
U   trunk/sched.c
U   trunk/utils.c

------------------------------------------------------------------------
r3273 | markster | 2008-01-15 15:00:09 -0600 (Tue, 15 Jan 2008) | 2 lines

Merge major BSD mutex and symbol conflict patches (bug ASTERISK-1791) (link patch still pending)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=3273