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

[Jason Parker]

----- Lee Essen <lee.essen at nowonline.co.uk> wrote:
> 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.
> 

I've been doing a bit of the work to get Asterisk running properly on Solaris, so I've seen a few of the issues you're running into.

4. I thought I had fixed this...guess not.
7. If you install fileutils, it will find and use ginstall instead of install-sh.
8. I've not seen this problem when using the blastwave curl package.
9. The version of id in /usr/xpg4/bin/ does support -un.  Is this in your PATH?
10. Do we just need to do a `$(INSTALL) -d $(DESTDIR)$(includedir)` here?
11. This was recently changed, and it will be fixed shortly.
13. You do indeed need gmake 3.81.  This requirement may be removed in the future (for tarball releases).

Please post a bug report for the rest.  It may make sense to group some of them together in one report.


-- 
Jason Parker
Digium