Re: apr-1 and apr-0

[Curt Arnold]

I think that you are experiencing a different problem that you suppose, 
but first to the problem that you think that you are having.

My original intent was that log4cxx could be built against either APR-0 
or APR-1, however there were enough differences that it was going to 
add a large amount of complexity.

None of the log4cxx methods take APR types, so there should be not 
problem having an application using both APR-0 and APR-1.

The Ant build script will build and link against static APR libraries, 
if no options that providing an installed APR location, like 
-Dapr.dir=/usr/local/lib, or explicitly requesting use of static 
libraries, like -Dapr.lib.type=shared,  are specified.  The behavior 
should be consistent on all platforms.

The make script predates the migration to APR, so I doubt that it gives 
you any control over the APR library type.

Are you sure that your log4cxx.so is linked against a shared APR-1?   
What happens if you do an "ldd log4cxx.so"?

Anyway, I don't think that is your problem.  I reviewed the stack trace 
and it suggested that I might have missed an place where we could get 
burned by an indeterminate sequence of static initialization.  That had 
been a cause of much grief 
(http://issues.apache.org/jira/browse/LOGCXX-4) and an effort was made 
to (almost) eliminate the use of non-local static instances.  However, 
there the Level::DEBUG et al public static member variables were too 
pervasively used in client code to eliminate.  The stack trace looks 
like the Level::OFF member variable is being initialized before APR has 
been initialized and reviewing the code indicated that that was indeed 
possible.  I've committed a fix that should ensure that APR is 
initialized before Level::OFF is initialized by calling 
APRInitializer::initialize() within the Level constructor.  Please 
update your CVS copy and see if the problem persists.  If the stack 
trace has changed, please post.