Summary:	ASTERISK-00503: Incompatible with uClibc
Reporter:	lth (lth)	Labels:
Date Opened:	2003-11-09 19:02:59.000-0600	Date Closed:	2011-06-07 14:10:14
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Well, I am fully aware that the authors of Asterisk have never claimed compatibility with uClibc, but actually it compiles and run well except for one minor problem in chan_sip.c (and chan_mgcp.c and chan_skinny.c - chan_iax2.c is fine). ****** ADDITIONAL INFORMATION ****** When using above mentioned channels compiled with uClibc, loading the modules result in the following warning: Cannot kill myself. Let me stress I am NOT a C programmer and does NOT have the big picture, but experimentally I tried to comment out the offending code in chan_sip.c and it seems to make it work perfectly (albeit I most likely broke something else in the process. This is the code after the comment was inserted:        /*if (monitor_thread == pthread_self()) {                ast_mutex_unlock(&monlock);                ast_log(LOG_WARNING, "Cannot kill myself\n");                return -1;        }*/ That's all - except from this piece of code (which exist in all the above mentioned channels) and the fact that uClibc does not include res_nsearch (used in dns.c) which is easily replaces with res_query, Asterisk compiles and works well with uClibc libraries instead of Glibc.  And it is much much smaller.
Comments:	By: Mark Spencer (markster) 2003-11-10 11:03:43.000-0600 Can you find a programmer (perhaps e-mail the list) who can confirm the changes and post a disclaimed patch? By: lth (lth) 2003-11-10 19:02:56.000-0600 Well - lets take the last part first :)  "My code" in the above consist of "/*" and "*/" - in other words - removing the above shown lines of code.  I hereby disclaim all ownership of C comments :) I actually posted the above as a question to the mailing list a few weeks back but nobody made any comments. I am sure this is caused by some missing stuff in uClibc thread handling, but I don't know enough about the inner workings of Asterisk to see what the purpose of the above piece of code is.  It doesn't excist in chan_iax2, but it excist in chan_sip, chan_mgcp and chan_skinny and it fails in all of them (ie. the warning is displayed and Asterisk does NOT receive the UDB packages - they are just queued up in the OS IP layer).  If the above mentioned lines of codes are removed - everything SEEMS to work.  But I am sure the above lines of codes are there for a purpose, so by removing them I may have introduced a bug that would show up in other cases. Regarding the other thing I mentioned - uClibc simply doesn't have the res_nsearch function.  As far as I can see - it might as well use res_query when compiled with uClibc. By: ep (ep) 2003-11-20 05:37:19.000-0600 I've tried to understand the problem.  I inserted a call to pthread_self() in the main asterisk executable, in loader.c, just after a module is opened and just before load_module() is called); there, pthread_self() returns the correct thread ID.  However, when pthread_self() is called from within an external module (I inserted a call in chan_sip's load_module(), just after the variable declarations) it returns 0.  It looks like pthread_self() is looking at the wrong data. I have tried a very quick workaround by inserting a new function in sched.c: pthread_t ast_pthread_self() { return pthread_self(); } and calling it instead of pthread_self() from the channel modules.  It seems to work, but I don't understand *why* it is behaving this way, and suspect that something else could be broken. edited on: 11-20-03 16:38 By: ep (ep) 2003-11-20 16:47:49.000-0600 As the previous comment probably implied, everything works perfectly leaving the code alone - in the channels, in loader.c and in sched.c - and just linking libpthread statically. That does not explain what exactly goes wrong in the interplay between uclibc, its implementations of the pthreads and its implementations of the dynamic loader, but I'd rather leave it to someone else - it would take me lots of time to learn about their innards! By: Brian West (bkw918) 2004-01-26 23:07:33.000-0600 Any way we can wrap that in an IFDEF?