[test-results] [Bamboo] Asterisk - 1.4 > CentOS 5.5 > #12 > i386 was SUCCESSFUL (with 42 tests). Change made by Tilghman Lesher.

[Bamboo]

-------------- next part --------------
----------------------------------------------------------------------------
Asterisk - 1.4 > CentOS 5.5 > #12 > i386 was successful.
----------------------------------------------------------------------------
Code has been updated by Tilghman Lesher.
42 tests in total.

http://bamboo.asterisk.org/browse/AST14-CENTOS55-I386-12/        


--------------
Code Changes
--------------
Tilghman Lesher (296867):

>Get rid of the annoying startup and shutdown errors on OS X.
>
>This mainly deals with the problem of constructors on platforms where an
>explicit constructor order cannot be specified (any system with gcc 4.2
>or less).  However, this is only a problem on those systems where we need
>to initialize mutexes with a constructor, because we have other code that
>also relies upon constructors, and we cannot specify that mutexes are
>initialized first (and destroyed last).
>
>There are two approaches to dealing with this issue, related to whether the
>code exists in the core Asterisk binary or in a separate code module.  In the
>core case, constructors are run immediately upon load, and the file_versions
>list mutex needs to be already initialized, as it is referenced in the first
>constructor within each core source file.  In this case, we use pthread_once
>to ensure that the mutex is initialized immediately before it is used for the
>first time.  The only caveat is that the mutex is not ever destroyed, but
>because this is the core, it makes no real difference; the only time when
>destruction is safe would be just prior to process destruction, which takes
>care of that anyway.  And due to using pthread_once, the mutex will never be
>reinitialized, which means only one structure has leaked at the end of the
>process.  Hence, it is not a problematic leak.
>
>The second approach is to use the load_module and unload_module routines,
>which, for obvious reasons, exist only in loadable modules.  In this second
>case, we don't have a problem with the constructors, but only with destructor
>order, because mutexes can be destroyed before their final usage is employed.
>However, we need the mutexes to still be destroyed, in certain scenarios:  if
>the module is unloaded prior to the process ending, it should be clean, with
>no allocations by the module hanging around after that point in time.
>


--------------
Error Summary
--------------
   Package gtk+-2.0 was not found in the pkg-config search path.
   Perhaps you should add the directory containing `gtk+-2.0.pc'
   to the PKG_CONFIG_PATH environment variable
   No package 'gtk+-2.0' found
   Package gtk+-2.0 was not found in the pkg-config search path.
   Perhaps you should add the directory containing `gtk+-2.0.pc'
   to the PKG_CONFIG_PATH environment variable
   No package 'gtk+-2.0' found


--
This message is automatically generated by Atlassian Bamboo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/test-results/attachments/20101130/93f1895b/attachment-0001.htm