[asterisk-dev] Cross compiling zaptel

Brian Capouch brianc at palaver.net
Wed Aug 22 02:39:15 CDT 2007

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;
         ret = *p;
         *p += v;
         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.


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

More information about the asterisk-dev mailing list