[asterisk-dev] [Code Review] Out-of-tree modules can fail because of compiler flag differences.

[Tilghman Lesher]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/508/#review1671
-----------------------------------------------------------



/branches/1.4/include/asterisk/lock.h
<https://reviewboard.asterisk.org/r/508/#comment3739>

    The removal of this is going to make certain types of lock issues more difficult to track down.
    
    Perhaps we'd be better served by making this macro into a function, so that it can be properly encapsulated for debug and non-debug cases?



/branches/1.4/main/lock.c
<https://reviewboard.asterisk.org/r/508/#comment3740>

    Looks like you have a second copy of the same file appended to this one here.  This usually occurs when you attempt to revert and reapply a patch, when a new file is already in the target path.


- Tilghman


On 2010-03-02 17:40:06, Jason Parker wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/508/
> -----------------------------------------------------------
> 
> (Updated 2010-03-02 17:40:06)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> When compiling modules out-of-tree, there is a large potential for ABI breakage, due to changing compiler flags.  If Asterisk is compiled with DEBUG_THREADS, and an out-of-tree module is not, it should not give undefined symbol errors during load (in fact, there's no reason it shouldn't work).  The biggest problem areas seemed to be DEBUG_THREADS and DEBUG_CHANNEL_LOCKS.
> 
> Is this the right way to go about this?
> 
> 
> Note: Many of the functions in lock.h had to be moved into a .c file (main/lock.c).  They were defined as static inline, which defeats much of the purpose.  A module *would* have the information about where a lock was obtained, but since it was including lock.h without DEBUG_THREADS enabled, it wouldn't bother logging it - even though Asterisk would really like it to.
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/include/asterisk/astobj2.h 249888 
>   /branches/1.4/include/asterisk/lock.h 249888 
>   /branches/1.4/main/Makefile 249888 
>   /branches/1.4/main/astobj2.c 249888 
>   /branches/1.4/main/channel.c 249888 
>   /branches/1.4/main/lock.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/508/diff
> 
> 
> Testing
> -------
> 
> Compile tests with/without DEBUG_THREADS and DEBUG_CHANNEL_LOCKS work great.  I've not tried building an external module with different flags yet.  I suspect that one would compile fine, but may not act properly, partially because of the note above.
> 
> 
> Thanks,
> 
> Jason
> 
>