logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barak Simon" <barak.si...@db.com>
Subject RE: I degrade some softwares on my computer, and now I can build log4cxx on Solaris 9 x86 now. But...
Date Thu, 21 Oct 2004 02:19:27 GMT

I guess it has to do with the static DEBUG_KEY as explained by carnold.

BTW, I have a question for you as well:
I have downgraded my automake and libtool but still get similar errors to the ones you had
when running autogen.sh.
Have you downgraded your autoconf and m4 as well?
I am using
autoconf (GNU Autoconf) 2.59, and
GNU m4 1.4.1
which are I think the original versions you used.

The errors I receive are attached below:

aclocal: configure.in: 32: macro `AM_PROG_LIBTOOL' not found in library
autoheader: error: AC_CONFIG_HEADERS not found in configure.in
configure.in:21: error: possibly undefined macro: AM_CONFIG_HEADER
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:27: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.in:32: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.in:86: error: possibly undefined macro: AM_CONDITIONAL
configure.in:27: no proper implementation of AM_INIT_AUTOMAKE was found,
configure.in:27: probably because aclocal.m4 is missing...
configure.in:27: You should run aclocal to create this file, then
configure.in:27: run automake again.
configure.in: installing `./install-sh'
configure.in: installing `./mkinstalldirs'
configure.in: installing `./missing'
examples/Makefile.am: installing `./depcomp'
/home/simobar/sun4u/build/pkgs/automake-1.6.3/share/automake-1.6/am/depend2.am: AMDEP does
not appear in AM_CONDITIONAL
/home/simobar/sun4u/build/pkgs/automake-1.6.3/share/automake-1.6/am/depend2.am: AMDEP does
not appear in AM_CONDITIONAL
/home/simobar/sun4u/build/pkgs/automake-1.6.3/share/automake-1.6/am/depend2.am: AMDEP does
not appear in AM_CONDITIONAL
/home/simobar/sun4u/build/pkgs/automake-1.6.3/share/automake-1.6/am/lang-compile.am: AMDEP
does not appear in AM_CONDITIONAL

PS - The script does complete, but then running "configure" fails.
(i.e. ./configure: line 1439: syntax error near unexpected token `AM_CONFIG_HEADER(include/log4cxx/config_auto.h)'
./configure: line 1439: `AM_CONFIG_HEADER(include/log4cxx/config_auto.h)')

Insights (from anyone) would be most welcome,

Barak Simon
GED IT Core Platform
190 George St. Sydney, 2000
Phone +61 2 925 85070
Fax      +61 2 925 95050

                                               To:       log4cxx-user@logging.apache.org 
                      21/10/2004 11:47         cc:                                       
                      Please respond to        Subject:  RE: I degrade some softwares on my
computer, and now I can build        log4cxx on Solaris 9   
                      log4cxx-user              x86 now. But...                          

Thanks to Simon. Your suggestion is very reasonable and enlighten me about
the factor ignored by me.
I try to simplified my program like the following, but I still get the same
output information and the program crash at the same line with the same

#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;

 void doIt();

 logger = Logger::getLogger(_T("MyApp"));

void Bar::doIt()
 logger->debug(_T("Did it again!"));

int main(int argc, char **argv)
 int result = EXIT_SUCCESS;


  Bar bar;
  result = EXIT_FAILURE;

 return result;

The following is the backtrace information:

(gdb) backtrace
#0  0xdd9fa8d7 in std::_Rb_tree<std::string, std::pair<std::string const,
tring>, std::_Select1st<std::pair<std::string const, std::string> >,
td::string>, std::allocator<std::pair<std::string const, std::string> >
std::string const&) const (this=0x0, __k=@0xdda5db14) at stl_tree.h:496
#1  0xdd9b7eb4 in log4cxx::helpers::Properties::getProperty(std::string
const (this=0x8047b00, key=@0xdda5db14) at stl_map.h:513
#2  0xdd9bcd01 in
roperties&, log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerRepository>&) (
   this=0x8047b50, properties=@0x8047b00, hierarchy=@0x8063394)
   at propertyconfigurator.cpp:149
#3  0xdd9bdc71 in log4cxx::PropertyConfigurator::doConfigure(std::string
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerRepository>&) (
   this=0x8047b50, configFileName=@0x8047c00, hierarchy=@0x8063394)
   at propertyconfigurator.cpp:119
#4  0xdd9be268 in log4cxx::PropertyConfigurator::configure(std::string
   (configFilename=@0x8047c00) at propertyconfigurator.cpp:124
#5  0x0805131b in main (argc=2, argv=0x8047c54) at log4cxxtest.cpp:49


Bill David

-----Original Message-----
From: Barak Simon [mailto:barak.simon@db.com]
Sent: Thursday, October 21, 2004 7:48 AM
To: log4cxx-user@logging.apache.org
Subject: Re: I degrade some softwares on my computer, and now I can build
log4 cxx on Solaris 9 x86 now. But...

In my experience, the best way currently to avoid the problem you are having
is do lazy initialisation
when you use log4cxx statics to initialise your own statics/globals.
For instance, when I needed to use a constant LevelPtr (e.g. Level::ERROR),
I used instead the log4cxx Level enums (i.e. Level::ERROR_INT)
and converted it to the LevelPtr static when actually using the level inside
my class method. At that stage the Level statics are already initialised.

This is also relevant to your lines:
LoggerPtr logger = Logger::getLogger(_T("MyApp")); and
LoggerPtr Bar::logger = Logger::getLogger(_T("MyApp"));

For the second line, I suggest trying instead:
LoggerPtr Bar::logger; (setting to zero if possible)
and in the ctor initing it:
logger = Logger::getLogger(_T("MyApp"));

For the first line, you can do the same (without the ctor part), but add a
global access GetLogger() method
to first init the logger if not initialised yet, and then return it.
(assuming LoggerPtr can be
assigned a zero or some default value which can be checked)

Hope this helps,

PS - I am now going to try downgrading my automake and libtool to the
versions working
for you! Maybe at last autogen.sh will actually work for me.
Barak Simon
GED IT Core Platform
Deutsche Bank
190 George St. Sydney, 2000
Phone +61 2 925 85070
 Fax      +61 2 925 95050


This e-mail may contain confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.

View raw message