[asterisk-dev] Cross compiling zaptel

[Brian Capouch]

I'm going to take Russell up on the offer he made Kristian wrt 
cross-building, even though I'm not Kristian and I'm not working on 
astlinux, and this is asterisk trunk, not zaptel :-)

I just did a checkout a few minutes ago, with a mind to seeing how well 
the SVN-trunk build would go against the latest (also fetched just now) 
openWRT kamikaze system.  Both are in "trunk" mode, so there's often a 
lot of fun as they both dodge around and change various paths, #defines, 
library versions, etc.

Here are some things I can report:

1. The openWRT build system now whines about virtually all the 
individual ~/app, ~/res, etc. .c files, with the following message on 
the console as each is encountered:

<built-in>:0: note: someone does not honour COPTS correctly, passed 0 times

2. I couldn't get the build to go at all until I added this code to the 
bottom of the files ~/utils/extconf.c and ~utils/check_expr.c:

AST_MUTEX_DEFINE_STATIC(fetchadd_m); /* used for all fetc&add ops */
int ast_atomic_fetchadd_int_slow(volatile int *p, int v)
{
         int ret;
         ast_mutex_lock(&fetchadd_m);
         ret = *p;
         *p += v;
         ast_mutex_unlock(&fetchadd_m);
         return ret;
}

I suspect that the object code for this function hasn't been compiled 
yet at the time that the build process enters ~/utils.  I cut and pasted 
it from somewhere else in the code--I'm too bleary-eyed now to remember 
where--and things built just fine.

Also, what's up with the identical source code for ast_expr2.c, being 
compiled twice in the build (in ~/utils and ~/main)?  I'm sure there 
must be a reason, and I hope it's not cheeky of me to ask why.  DRY and all.

3. Speaking of ast_expr2.c, I still suffer from the openWRT build 
choking on some math functions, namely REMAINDER ROUND and TRUNC.  That 
is beyond the problem I reported before, which is the definition of 
__USE_ISOC99, which causes the 'l' versions of all these functions to be 
selected instead of the vanilla ones.  The comment in the source code at 
the point of the #ifdef on this value (from murph) is not very reassuring.

I just got it to build; running it will have to wait for the morrow.

B.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.