[asterisk-dev] ast_atomic_fetchadd_int_slow and cross-compiles feedback

[Brian Capouch]

I'm trying to watch the commits, but I'm missing some.  I want to watch 
how all this gets resolved, but it's starting to become like whack-a-mole.

I think file is the one doing the work on ~utils/check_expr.c and 
~utils/extconfig.c?

The history goes like this:

* I used to have to always manually move this function (from 
~main/utils.c) into those two files before I could cross-compile.

* One day a week or so ago, after seeing a commit from Josh, extconfig.c 
built without my having to modify it.  check_expr.c still had to have 
the function pasted in for it to compile.

* Then, soon thereafter, despite the fact that it was still there, the 
compile couldn't see the definition anymore in extconfig.c, either.  The 
trailing #else that led to this definition:

	#else
	AST_INLINE_API(int ast_atomic_fetchadd_int(volatile int *p, int
  v),
		return ast_atomic_fetchadd_int_slow(p, v);
	#endif

wasn't getting hit.  Why?  That's still the case today for my 
cross-compiles under openWRT.

The fix is to remove the #else/#endif so that it's always defined.  This 
seems very strange to me, since none of the other cases in that #if 
defined series should fire. . .

* Starting with today's checkout, ast_atomic_fetchadd_int_slow is now in 
check_expr.c.  Yay!!  It's done differently than in extconfig.c, but it 
works fine.

So, as things stand, my builds go great if in extconfig.c I change the 
trailing #else into an unconditional definition.  I could *swear* for 
one build only, very recently, I didn't have to do that.

I lost the link that shows me a commit-by-commit list of changes to the 
trunk source.

I'd love to get clued in on this.  It's *almost* there. . . it's the 
next-to-last "issue" with my cross builds.

b.
		

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