Re: Static initialization order (was Re: I degrade some softwares on my computer ...)

Bill,

there's nothing you can do influence the order of global static 
initialization. It can go wrong any time it pleases. I found that 
callig "doConfigure" (or similar) gets the initialization done (see my 
previous posts about two months ago).

HTH,
Sven

On 21.10.2004, at 04:20, Xiong, Wei (Wei) wrote:

> Thank you and Simon. But I tried the same program with the .so file 
> built
> from my own makefile (I just write a config_auto.h for it and compile 
> every
> .cpp file to .o and pack them together), it runs very well. And in my 
> demo
> program, I have include standard log4cxx  .h files before my 
> definition of
> Bar::logger. Will not the log4cxx global static be constructed before 
> the
> construction of Bar::logger?
> Besides, in my simplified program, I am sure all the global static 
> variables
> have been constructed before I call any log4cxx function explicitly. 
> But I
> got the same output and crash info. I tried my old program (with a 
> global
> static 'LoggerPtr logger = Logger::getLogger(_T("MyApp"));') again, the
> logger has a valid value.
>
> (gdb) p logger
> $1 = {p = 0x80630c8}
> (gdb) p logger->p
> $2 = (Logger *) 0x80630c8
>
> And the crash info shows that the program just collapse when it is 
> parsing
> the configuration file. But I really don't know more about what the 
> crash
> info means.
>
> // my simplified program
>
> #include <log4cxx/logger.h>
> #include <log4cxx/basicconfigurator.h>
> #include <log4cxx/helpers/exception.h>
> #include <log4cxx/propertyconfigurator.h>
> #include <log4cxx/xml/domconfigurator.h>
> #include <log4cxx/helpers/loglog.h>
>
> using namespace log4cxx;
> using namespace log4cxx::helpers;
> using namespace log4cxx::xml;
>
> class Bar
> {
>         log4cxx::LoggerPtr logger;
>
> public:
>         Bar();
>         void doIt();
> };
>
> Bar::Bar()
> {
>         logger = Logger::getLogger(_T("MyApp"));
> }
>
> void Bar::doIt()
> {
>         logger->debug(_T("Did it again!"));
> }
>
>
> int main(int argc, char **argv)
> {
>         int result = EXIT_SUCCESS;
>
>         try
>         {
>                 DOMConfigurator::configure(argv[1]);
>                 
>                 Bar bar;
>                 bar.doIt();
>         }
>         catch(Exception&)
>         {
>                 result = EXIT_FAILURE;
>         }
>
>         return result;
> }
>
> Regards,
>
> Bill David
> 2004.10.21
>
>
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@xxxxxxxxxx]
> Sent: Thursday, October 21, 2004 8:24 AM
> To: Log4CXX User
> Subject: Static initialization order (was Re: I degrade some softwares 
> on my
> computer ...)
>
>
> Thanks, the traceback is consistent with attempting to configure before
> the static string DEBUG_KEY has been constructed.  I've just completed
> a fairly wide-ranging patch that eliminates use of non-local static
> variables (see item 47 in Effective C++ for background) within log4cxx.
>     However, the bug database has been having problems for a couple of
> hours and so I can't get a bug number to use in the commit.  If it
> stays down another hour, I'll do the commit anyway.
>
> The most commonly used non-local static variables are the
> log4cxx::Level::DEBUG and similar level "constants".  I could not
> remove those without breaking almost all code that uses log4cxx, so
> I've left them in but added accessors, log4cxx::Level::getDebug(), etc
> that are safe for use at any time and changed all references to
> log4cxx::Level::DEBUG inside log4cxx to use the accessor.