[asterisk-dev] Some 1.4.0-beta2 and Solaris 10 issues...

[Lee Essen]

Hi,

I'm not sure if anyone is tracking Solaris support for Asterisk here, 
but these may be of interest and some of the issues may actually exist 
on other platforms ... I can raise these all in the bug tracker if 
needed, so please advise the best thing to do.

It's been a bit of a mammoth session trying to get this to work (with 
the mutex issue being particularly awkward) so I apologise for the 
length of this ... but it at least builds and runs on Solaris 10, 
testing actual calls will follow later! :-)

Regards,

Lee.


1. Linked List Mutex issue -- this looks like a generic problem

In lock.h, for static AST_MUTEX's the define (__AST_MUTEX_DEFINE) has a 
constructor that calls ast_mutex_init() which ensures the type is set to 
PTHREAD_MUTEX_RECURSIVE, this is all great and works perfectly, however 
if you look at linkedlist.h you will see that AST_LIST_HEAD_STATIC has 
an ast_mutex_t field that is given an initial value but not subsequently 
ast_mutex_init'ed, on Solaris this causes it to not be a 
PTHREAD_MUTEX_RECURSIVE and causes Asterisk to deadlock on loading modules.

As a workaround I've added the constructor and destructor to the 
AST_LIST_HEAD_STATIC routine and it works fine, but the final solution 
will need to be somewhat more complex given the arrangement of #ifdef's 
in lock.h.

2. DEBUG_THREAD and comparing structs??

If you turn on DEBUG_THREAD then lock.h does a number of struct 
comparisons that are invalid and cause the compilation to fail, I did 
experiment with using memcmp instead but didn't manage to get it to work 
properly.

For reference these are generally comparisons of t->mutex with either 
PTHREAD_MUTEX_INITIALIZER or (empty_mutex).

3. Missing cast of PTHREAD_MUTEX_INITIALIZER

Still in lock.h, at the end of __ast_pthread_mutex_destroy there is an 
assignment to t->mutex which fails to compile unless you cast it to 
(pthread_mutex_t). I think this was only with DEBUG_THREAD set.

4. build_tools/prep_moduledeps ... "-e"

On Solaris both grep and echo don't take a "-e" option, the grep fails 
and the echo causes an extra "-e" in the output. Removing the "-e" seems 
to work fine (although see later about C++ files.)

5. build_tools/get_moduleinfo and build_tools/get_makeopts

On Solaris awk doesn't like empty expressions (//) and fails to build 
all of the dependency stuff. Removing the // works fine ... I'm not 
aware of this being a problem with any other awk's so this should be an 
easy one!

6. menuselect-tree issues with C++ files (vpb and kdeconsole)

For C++ source files the menuselect-tree file seems to have an extra "." 
which causes the dependencies to fail (i.e. "vpb." and "vpb..o" etc.)

I haven't dug into this in any detail yet and could be related to the 
previous issues.

7. install-sh problems

By default the install-sh script is picked but used as "./install-sh" 
which is fine until the make sequence moves into another directory. In 
addition install-sh uses "mv" by default which moves all the include 
files out of the way causes later installs to fail.

This is easily fixed by using INSTALL="/usr/ucb/install", but it would 
be good if it detected this automatically.

8. curl include path

Not really an asterisk issue, but for some reason the SunFreeWare curl 
package doesn't return the include info from curl-config (the lib stuff 
is fine) ... would be nice to have that as a "configure" option -- at 
the moment I have to hack the makeopts file.

9. "id" command options in Makefile

On Solaris the "id" command does not take the "-un" options, the easiest 
fix here would be to use $LOGNAME or $USER.

10. $includedir in Makefile bininstall

In the bininstall section $(DESTDIR)$(ASTHEADERDIR) is created, but 
$(DESTDIR)$(includedir) which is used immediately after is not created, 
causing problems if they happen to be different (which they are by 
default on Solaris.)

11. tar in sounds/Makefile

Solaris tar does not take "C" as an option (tar xCf) ... gtar is 
available and works perfectly.

12. wait4 different usage between Solaris and Linux

In main/asterisk.c wait4(-1,...) is used, on Solaris the same behaviour 
actually needs a wait4(0,...) -- you'll have lots of AGI zombie 
processes around if left unchanged.

13. FYI ... Solaris make is rubbish and gmake is too old.

By default Solaris has "gmake" (gnu make) v3.80 which fails with a 
"virtual memory exhausted" error, and the default Solaris "make" doesn't 
get anywhere.

Upgrading to gnu make v3.81 fixes the memory problem.