log4cpp-devel — technical discussions about the development of log4cpp

RE: [Log4cpp-devel] HP-UX/gcc3.0.1/int64_t

[Bastiaan B. <Bas...@li...>]

This has been fixed in m4/AC_C_INT64_T.m4 a few weeks ago. It is =
available from CVS and will be in 0.3.2 .

Regards,

Bsstiaan Bakker
LifeLine Networks bv=20

> -----Original Message-----
> From: Thomas Porschberg [mailto:tho...@os...]
> Sent: Tuesday, May 14, 2002 1:25 PM
> To: Thomas Porschberg
> Cc: log...@li...
> Subject: Re: [Log4cpp-devel] HP-UX/gcc3.0.1/int64_t
>=20
>=20
> Okay, I commented out
> the lines for the #define LOG4CPP_HAVE_INT64_T
> in include/log4cpp/config.h.
>=20
> But this is not the best way...
>=20
>=20
> On Tue, May 14, 2002 at 01:05:28PM +0200, Thomas Porschberg wrote:
> >=20
> > I tried to compile on HPUX11 with gcc3.0.1 and the
> > configure - script reported:
> > .
> > .
> > .
> > checking for int64_t... yes
> > .
> > .
> > .
> >=20
> > but the compilation of PatternLayout.cpp failed:
> >=20
> > PatternLayout.cpp: In member function `std::string=20
> >    log4cpp::PatternLayout::doFormat(const log4cpp::LoggingEvent&,=20
> >    std::basic_string<char, std::char_traits<char>,=20
> std::allocator<char> >,=20
> >    bool*)':
> > PatternLayout.cpp:128: `int64_t' undeclared (first use this=20
> function)
> > PatternLayout.cpp:128: (Each undeclared identifier is=20
> reported only once for=20
> >    each function it appears in.)
> > PatternLayout.cpp:128: parse error before `=3D' token
> > PatternLayout.cpp:130: `t' undeclared (first use this function)
> > *** Error exit code 1
> >=20
> > I used this shellscript:
> >=20
> > #!/bin/ksh
> >=20
> > unset CFLAGS
> > export PATH=3D"/opt/gcc/bin:$PATH"
> > export CXXFLAGS=3D'-g -Wall -pedantic'
> > ./configure --prefix=3D/opt --enable-shared=3Dno
> >=20
> > make
> >=20
> > How to overcome this error ?
> >=20
> > thomas
> >=20
> > --=20
> >=20
> > _______________________________________________________________
> >=20
> > Have big pipes? SourceForge.net is looking for download=20
> mirrors. We supply
> > the hardware. You get the recognition. Email Us:=20
> ban...@so...
> > _______________________________________________
> > Log4cpp-devel mailing list
> > Log...@li...
> > https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>=20
> --=20
>=20
> _______________________________________________________________
>=20
> Have big pipes? SourceForge.net is looking for download=20
> mirrors. We supply
> the hardware. You get the recognition. Email Us:=20
> ban...@so...
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>=20

Re: [Log4cpp-devel] HP-UX/gcc3.0.1/int64_t

[Thomas P. <tho...@os...>]

Okay, I commented out
the lines for the #define LOG4CPP_HAVE_INT64_T
in include/log4cpp/config.h.

But this is not the best way...


On Tue, May 14, 2002 at 01:05:28PM +0200, Thomas Porschberg wrote:
> 
> I tried to compile on HPUX11 with gcc3.0.1 and the
> configure - script reported:
> .
> .
> .
> checking for int64_t... yes
> .
> .
> .
> 
> but the compilation of PatternLayout.cpp failed:
> 
> PatternLayout.cpp: In member function `std::string 
>    log4cpp::PatternLayout::doFormat(const log4cpp::LoggingEvent&, 
>    std::basic_string<char, std::char_traits<char>, std::allocator<char> >, 
>    bool*)':
> PatternLayout.cpp:128: `int64_t' undeclared (first use this function)
> PatternLayout.cpp:128: (Each undeclared identifier is reported only once for 
>    each function it appears in.)
> PatternLayout.cpp:128: parse error before `=' token
> PatternLayout.cpp:130: `t' undeclared (first use this function)
> *** Error exit code 1
> 
> I used this shellscript:
> 
> #!/bin/ksh
> 
> unset CFLAGS
> export PATH="/opt/gcc/bin:$PATH"
> export CXXFLAGS='-g -Wall -pedantic'
> ./configure --prefix=/opt --enable-shared=no
> 
> make
> 
> How to overcome this error ?
> 
> thomas
> 
> -- 
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

-- 

[Log4cpp-devel] HP-UX/gcc3.0.1/int64_t

[Thomas P. <tho...@os...>]

I tried to compile on HPUX11 with gcc3.0.1 and the
configure - script reported:
.
.
.
checking for int64_t... yes
.
.
.

but the compilation of PatternLayout.cpp failed:

PatternLayout.cpp: In member function `std::string 
   log4cpp::PatternLayout::doFormat(const log4cpp::LoggingEvent&, 
   std::basic_string<char, std::char_traits<char>, std::allocator<char> >, 
   bool*)':
PatternLayout.cpp:128: `int64_t' undeclared (first use this function)
PatternLayout.cpp:128: (Each undeclared identifier is reported only once for 
   each function it appears in.)
PatternLayout.cpp:128: parse error before `=' token
PatternLayout.cpp:130: `t' undeclared (first use this function)
*** Error exit code 1

I used this shellscript:

#!/bin/ksh

unset CFLAGS
export PATH="/opt/gcc/bin:$PATH"
export CXXFLAGS='-g -Wall -pedantic'
./configure --prefix=/opt --enable-shared=no

make

How to overcome this error ?

thomas

-- 

[Log4cpp-devel] [matis@osp-dd.de: [Fwd: Postmaster notify: see transcript for details]]

[Thomas P. <tho...@os...>]

Is it possible to use log4cpp with gcc3.0.1 ?

I tried to compile under Linux (SuSE 7.3) and
HPUX (gcc3.0.1 too) log4cpp-0.2.7, but it failed 

(please reply to tho...@os...)

here my small wrapper script for start configure:

unset CFLAGS
export PATH="/opt/gcc/gcc-3.0.1/bin:$PATH"
export CC=/opt/gcc/gcc-3.0.1/bin/gcc
export CXX=/opt/gcc/gcc-3.0.1/bin/g++
export CXXFLAGS='-g -Wall -pedantic'
../configure --prefix=/opt

and OUTPUT from configure:

checking for a BSD compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking build system type... i586-pc-linux-gnu
checking host system type... i586-pc-linux-gnu
checking for gcc... /opt/gcc/gcc-3.0.1/bin/gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... 
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether /opt/gcc/gcc-3.0.1/bin/gcc accepts -g... yes
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking command to parse /usr/bin/nm -B output... ok
checking how to run the C preprocessor... /opt/gcc/gcc-3.0.1/bin/gcc -E
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for /opt/gcc/gcc-3.0.1/bin/gcc option to produce PIC... -fPIC
checking if /opt/gcc/gcc-3.0.1/bin/gcc PIC flag -fPIC works... yes
checking if /opt/gcc/gcc-3.0.1/bin/gcc static flag -static works... yes
checking if /opt/gcc/gcc-3.0.1/bin/gcc supports -c -o file.o... yes
checking if /opt/gcc/gcc-3.0.1/bin/gcc supports -c -o file.lo... no
checking if /opt/gcc/gcc-3.0.1/bin/gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool
checking for a BSD compatible install... /usr/bin/ginstall -c
checking whether make sets ${MAKE}... (cached) yes
checking whether we are using the GNU C++ compiler... yes
checking whether /opt/gcc/gcc-3.0.1/bin/g++ accepts -g... yes
checking how to run the C++ preprocessor... /opt/gcc/gcc-3.0.1/bin/g++ -E
checking for unistd.h... yes
checking for io.h... no
checking for int64_t... yes
checking whether the compiler implements namespaces... yes
checking whether the compiler has stringstream... yes
checking for working snprintf... yes
checking for syslog... yes
checking for gettimeofday... yes
checking for ftime... yes
checking for strcasecmp... yes
checking for socket in -lsocket... no
checking for gethostbyname in -lnsl... yes
checking for doxygen... /usr/bin/doxygen
checking for dot... /usr/local/bin/dot
creating log4cpp-config - generic 0.2.7 of log4cpp -lnsl
configure: creating ./config.status
config.status: creating Makefile
config.status: creating log4cpp.spec
config.status: creating config/Makefile
config.status: creating doc/Makefile
config.status: creating doc/Doxyfile
config.status: creating src/Makefile
config.status: creating include/Makefile
config.status: creating include/log4cpp/Makefile
config.status: creating tests/Makefile
config.status: creating debian/Makefile
config.status: creating msvc6/Makefile
config.status: creating msvc6/log4cpp/Makefile
config.status: creating msvc6/testCategory/Makefile
config.status: creating msvc6/testNDC/Makefile
config.status: creating bcb5/Makefile
config.status: creating bcb5/log4cpp/Makefile
config.status: creating bcb5/testCategory/Makefile
config.status: creating bcb5/testConfig/Makefile
config.status: creating bcb5/testFixedContextCategory/Makefile
config.status: creating bcb5/testmain/Makefile
config.status: creating bcb5/testNDC/Makefile
config.status: creating bcb5/testPattern/Makefile
config.status: creating openvms/Makefile
config.status: creating include/config.h
config.status: include/config.h is unchanged
creating include/log4cpp/config.h - prefix LOG4CPP for include/config.h defines
/* automatically generated bcb5/ config/ debian/ doc/ include/ m4/ msvc6/ openvm
s/ src


OUTPUT from make:
..
..
..
/opt/gcc/gcc-3.0.1/bin/g++ -g -Wall -pedantic -Wall -pedantic -o .libs/testmain testmain.o  ../src/.libs/liblog4cpp.so -lnsl -Wl,--rpath -Wl,/opt/lib
.../src/.libs/liblog4cpp.so: undefined reference to `std::codecvt<char, char, __mbstate_t>::id'
collect2: ld returned 1 exit status
make[1]: *** [testmain] Error 1



===========================================================================

OUTPUT FROM HP-UX:
/opt/gcc/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../include -I../include -g -Wall -pedantic -Wall -pedantic -c PatternLayout.cpp  -fPIC -DPIC -o PatternLayout.o
PatternLayout.cpp: In member function `std::string 
   log4cpp::PatternLayout::doFormat(const log4cpp::LoggingEvent&, 
   std::basic_string<char, std::char_traits<char>, std::allocator<char> >, 
   bool*)':
PatternLayout.cpp:128: `int64_t' undeclared (first use this function)
PatternLayout.cpp:128: (Each undeclared identifier is reported only once for 
   each function it appears in.)
PatternLayout.cpp:128: parse error before `=' token
PatternLayout.cpp:130: `t' undeclared (first use this function)
*** Error exit code 1

Stop.
*** Error exit code 1

========================================================================

Please reply to tho...@os...
-- 

RE: [Log4cpp-devel] AsyncAppender and others

[Bastiaan B. <Bas...@li...>]

> -----Original Message-----
> From: LECLERCQ Nicolas [mailto:nic...@so...]
> Sent: Friday, May 03, 2002 12:04 PM
> To: log...@li...
> Subject: [Log4cpp-devel] AsyncAppender and others
>=20
>=20
> Hi there,
> After a preliminary discussion with Bastiaan, I suggest to=20
> had to following features to log4cpp:
>=20
> 1 - AsyncAppender class.=20
>=20
> The log4j doc says: <The AsyncAppender lets users log events=20
> asynchronously. It uses a bounded buffer to store logging=20
> events. It will collect the events sent to it and then=20
> dispatch them to all the appenders that are attached to it.=20
> You can attach multiple appenders to an AsyncAppender. The=20
> AsyncAppender uses a separate thread to serve the events in=20
> its bounded buffer>.
>=20
> In order to write the AsyncAppender, we first need to=20
> implement an AppenderAttachable class that could be shared=20
> between the Category class and the AsyncAppender class (code=20
> factorization).  All the existing code dedicated to  the=20
> Appenders management (i.e. such as addAppender,=20
> removeAppender, ...) should be encapsulated in the=20
> AppenderAttachable class.
>=20

Yes, good idea. The appender stuff in Category is an ugly mess right =
now, due to object ownership issues. I feel a better way than having the =
ownsAppender data would be to have the Hierarchy always own the =
appenders or do refcounting. Suggestions are welcome.
=20
> Then we need a log4cpp::threading::Thread class. That's not a=20
> big problem but we have to choose an interface compatible=20
> with (potentially) all underlying implementation of threads.=20
> Since the need is basic, only the fundamental features are=20
> required and the Thread class interface could be something like:=20
>=20

Hmm, I don't know whether log4cpp itself needs a complete thread object =
interface. We could make the AsyncAppender a Runnable (i.e. put the main =
loop in a method named run()) and let the app worry about starting it. I =
suggest first writing the AsyncAppender that way and have the apps do =
the thread control.=20
After people have written the right code for several threading libs it's =
easier to see a minimal abstraction. (For example, I suspect we may not =
need join() or yield()).
I wouldn't want to see a large chunk of code for thread abstraction of =
thread abstraction libraries in log4cpp. It's logging library, not a =
thread library after all.

> class Thread  [: private myPreferredThreadingPackage::Thread ] {
>=20
> public :
> =09
>  // Define only 3 levels of priority.
>  enum {
>     THREAD_PRIORITY_LOW =3D 0,
>     THREAD_PRIORITY_NORMAL,=09
>     THREAD_PRIORITY_HIGH,=09
>  } Priority;
>=20
>   Thread (const char* name);
>   Thread (const std::string& name);
>   // Ctors
>=20
>   virtual ~Thread();
>   // Dtors
>=20
>   int start (void);
>   // Start the thread.
>=20
>   virtual void run (void) =3D  0;
>   // Override this method to provide functionality to your thread.
>=20
>   void join (long milli_secs =3D 0);
>   // Wait at most milli_secs for this thread to terminate. If=20
> milli_secs =3D=3D 0 then wait for ever.
>=20
>   void setPriority (int new_prio);
>   // Set the priority of this thread.
>=20
>   int  getPriority (void) const;   =20
>   // Get the priority of this thread.=20
>=20
>   //... anything else? sleep, yield, ...
>=20
> };
> =20
> The last thing we need to implement the AsyncAppender class=20
> is something similar to the log4j BoundedFIFO. The STL queue=20
> is perfectly adapted to implement such a class.
>=20

Yes, this should be straightforward to implement.

>=20
>=20
> 2 - Log4Cpp class.
>=20
> The aim of the Log4Cpp class is to encapsulate the=20
> init/shutdown stuffs.=20
>=20
> class Log4Cpp {
> public:
>     static int init (void);
>     // Initializer. Return -1 on error, 0 otherwise.
>=20
>     static void shutdown (void);
>     // Cleanup everything before quitting.=20
> };
>=20
> Some packages (such as Java Threads for C++) need to be=20
> initialized to work properly. The Log4Cpp::init could be a=20
> good place for that. The Category::shutdown call could also=20
> be moved to  Log4Cpp::shutdown.=20
>=20

Yes, a proper initialization and shutdown method are useful. However we =
should be careful to allow implicit calling of init() through static =
initilializers (I don't know whether this is allowed for JTC),  because =
people may want to put their Category references in static variables. =
E.g.:

static log4cpp::Category =
SomeClass::_log(log4cpp::Category::getInstance("SomeClass"));


> 3 - Logger and Level classes
>=20
> Just to reflect log4j 1.2 changes.

We could simply add these as typedefs of Category and Priority for now?

Regards,

Bastiaan Bakker
LifeLine Networks bv


>=20
> I'm looking forward to your reactions.
>=20
> Nicolas
> SOLEIL project - http://www.soleil.u-psud.fr.
>=20
>=20
> _______________________________________________________________
>=20
> Have big pipes? SourceForge.net is looking for download=20
> mirrors. We supply
> the hardware. You get the recognition. Email Us:=20
> ban...@so...
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>=20

[Log4cpp-devel] AsyncAppender and others

[LECLERCQ N. <nic...@so...>]

Hi there,
After a preliminary discussion with Bastiaan, I suggest to had to =
following features to log4cpp:

1 - AsyncAppender class.=20

The log4j doc says: <The AsyncAppender lets users log events =
asynchronously. It uses a bounded buffer to store logging events. It =
will collect the events sent to it and then dispatch them to all the =
appenders that are attached to it. You can attach multiple appenders to =
an AsyncAppender. The AsyncAppender uses a separate thread to serve the =
events in its bounded buffer>.

In order to write the AsyncAppender, we first need to implement an =
AppenderAttachable class that could be shared between the Category class =
and the AsyncAppender class (code factorization).  All the existing code =
dedicated to  the Appenders management (i.e. such as addAppender, =
removeAppender, ...) should be encapsulated in the AppenderAttachable =
class.

Then we need a log4cpp::threading::Thread class. That's not a big =
problem but we have to choose an interface compatible with (potentially) =
all underlying implementation of threads. Since the need is basic, only =
the fundamental features are required and the Thread class interface =
could be something like:=20

class Thread  [: private myPreferredThreadingPackage::Thread ] {

public :
=09
 // Define only 3 levels of priority.
 enum {
    THREAD_PRIORITY_LOW =3D 0,
    THREAD_PRIORITY_NORMAL,=09
    THREAD_PRIORITY_HIGH,=09
 } Priority;

  Thread (const char* name);
  Thread (const std::string& name);
  // Ctors

  virtual ~Thread();
  // Dtors

  int start (void);
  // Start the thread.

  virtual void run (void) =3D  0;
  // Override this method to provide functionality to your thread.

  void join (long milli_secs =3D 0);
  // Wait at most milli_secs for this thread to terminate. If milli_secs =
=3D=3D 0 then wait for ever.

  void setPriority (int new_prio);
  // Set the priority of this thread.

  int  getPriority (void) const;   =20
  // Get the priority of this thread.=20

  //... anything else? sleep, yield, ...

};
=20
The last thing we need to implement the AsyncAppender class is something =
similar to the log4j BoundedFIFO. The STL queue is perfectly adapted to =
implement such a class.



2 - Log4Cpp class.

The aim of the Log4Cpp class is to encapsulate the init/shutdown stuffs. =


class Log4Cpp {
public:
    static int init (void);
    // Initializer. Return -1 on error, 0 otherwise.

    static void shutdown (void);
    // Cleanup everything before quitting.=20
};

Some packages (such as Java Threads for C++) need to be initialized to =
work properly. The Log4Cpp::init could be a good place for that. The =
Category::shutdown call could also be moved to  Log4Cpp::shutdown.=20

3 - Logger and Level classes

Just to reflect log4j 1.2 changes.

I'm looking forward to your reactions.

Nicolas
SOLEIL project - http://www.soleil.u-psud.fr.

[Log4cpp-devel] Problems compiling 0.3.1 on msvc6

[Weber, Mathias-H. 1. S-WF-R. <Mat...@de...>]

Hi,

has anybody ever tried to compile 0.3.1 on msvc6? I get lots off error
messages starting with

    fileappender.hh(32) : error C2629: unexpected 
                           'class log4cpp::FileAppender ('

Compiling of 0.2.7 went through without a single complaint.

Any hint is appreciated.

Mathias

[Log4cpp-devel] 0.3.1 released

[Bastiaan B. <bas...@li...>]

Hi all,

I've put release 0.3.1 on SourceForge. The update consist mainly of bugs 
fixed since 0.3.0 and the addition of the RollingFileAppender 
contributed by Paulo Pizarro.
This releases has been dist-checked on RH Linux 7.2 only, as it is still 
a work in progress. If it is broken on your platform please fix and/or 
report.

Cheers,

Bastiaan Bakker

Re: [Log4cpp-devel] problem with Category::removeAllAppenders

[Bastiaan B. <bas...@li...>]

Hi,

Yes, I see the stupid bug now, a misplaced '}'.  Thanks for reporting it!

Bastiaan

Jak...@no... wrote:

>Hi,
>
>Yes, now I see that bug description.
>But I have taken most current version from cvs ...
>it is commented "fix invalidated iterator usage. (bug #527467)"
>and it is 1.34.
>
>It still causes problem int13 ;-)
>
>problem is with delete (*i) and then doing i++.
>other problem is that _ownsAppender.clear() and _appender.clear()
>are put in for loop. So they are run in thirst iteration ...
>In bug description they are run after for, which make sense.
>
>
>
>    void Category::removeAllAppenders() {
>        threading::ScopedLock lock(_appenderSetMutex);
>        {
>            for (AppenderSet::iterator i = _appender.begin();
>                 i != _appender.end(); i++) {
>                // found
>                OwnsAppenderMap::iterator i2;
>                if (ownsAppender(*i, i2)) {
>                    delete (*i);
>                }
>               
>                _ownsAppender.clear();
>                _appender.clear();
>            }
>        }
>    }
>
>
>cheers,
>--jakub
>
> 
> 
>
>
>>-----Original Message-----
>>From: ext Bastiaan Bakker [  <mailto:bas...@li...> mailto:bas...@li...]
>>Sent: 2. april 2002 22:48
>>To: Szymanski Jakub (NET/Copenhagen)
>>Cc: log...@li...
>>Subject: Re: [Log4cpp-devel] problem with Category::removeAllAppenders
>>
>>
>>Hi Jakub,
>>
>>This is a known bug (#527467) and a fix has been committed to
>>CVS (HEAD
>>branch). I intend to release 0.3.1 (containing the fix) later
>>this week.
>>
>>Thanks,
>>
>>Bastiaan Bakker
>>LifeLine Networks bv
>>
>>Jak...@no... wrote:
>>
>>>Hi,
>>>
>>>I run log4cpp on VC6.0 SP5. Version 0.30 + Category and Appender
>>>
>>>from CVS.
>>
>>>I have problem with Category::removeAllAppenders.
>>>Version 1.34 (most current in CVS).
>>>
>>>When I run testCategory (or my simple tests) I have
>>>Unhandled exception Access Violation
>>>with stack trace:
>>>[ ....cut ...]
>>>log4cpp::Category::removeAllAppenders() line 152 + 16 bytes
>>>main(int 1, char * * 0x004417d0) line 144 + 13 bytes
>>>mainCRTStartup() line 338 + 17 bytes
>>>KERNEL32! 77f1ba06()
>>>
>>>
>>>There is:
>>>   void Category::removeAllAppenders() {
>>>       threading::ScopedLock lock(_appenderSetMutex);
>>>       {
>>>           for (AppenderSet::iterator i = _appender.begin();
>>>                i != _appender.end(); i++) {
>>>               // found
>>>               OwnsAppenderMap::iterator i2;
>>>               if (ownsAppender(*i, i2)) {
>>>                   delete (*i);
>>>               }
>>>              
>>>               _ownsAppender.clear();
>>>               _appender.clear();
>>>           }
>>>       }
>>>   }
>>>
>>>
>>>Problem is with delete of current iterator. Acording to specs and
>>>good comment in Appender.cpp you can't use iterator after
>>>
>>deleteing it
>>
>>>[
>>>Appender::_deleteAllAppenders()
>>>--- cut ---
>>>           i++; // increment iterator before delete or
>>>
>>iterator will be invalid.
>>
>>>           delete (app);
>>>]
>>>
>>>
>>>So I changed code to:
>>>   void Category::removeAllAppenders() {
>>>       threading::ScopedLock lock(_appenderSetMutex);
>>>       {
>>>           Appender* app;
>>>           AppenderSet::iterator i2;
>>>
>>>           for (AppenderSet::iterator i = _appender.begin();
>>>                i != _appender.end(); ) {
>>>               // found
>>>               app = *i;
>>>               i2 = i;
>>>               i++;
>>>
>>>               OwnsAppenderMap::iterator i3;
>>>               if (ownsAppender(*i2, i3)) {
>>>                   delete app;
>>>               }
>>>            }
>>>               
>>>               _ownsAppender.clear();
>>>               _appender.clear();
>>>       }
>>>   }
>>>
>>>and it passes testCategory test.
>>>
>>>cheers,
>>>--jakub
>>>
>>>
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>Log4cpp-devel mailing list
>>>Log...@li...
>>> <https://lists.sourceforge.net/lists/listinfo/log4cpp-devel> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>>>
>>
>>
>
>

RE: [Log4cpp-devel] problem with Category::removeAllAppenders

[<Jak...@no...>]

Hi,

Yes, now I see that bug description.
But I have taken most current version from cvs ...
it is commented "fix invalidated iterator usage. (bug #527467)"
and it is 1.34.

It still causes problem int13 ;-)

problem is with delete (*i) and then doing i++.
other problem is that _ownsAppender.clear() and _appender.clear()
are put in for loop. So they are run in thirst iteration ...
In bug description they are run after for, which make sense.



    void Category::removeAllAppenders() {
        threading::ScopedLock lock(_appenderSetMutex);
        {
            for (AppenderSet::iterator i =3D _appender.begin();
                 i !=3D _appender.end(); i++) {
                // found
                OwnsAppenderMap::iterator i2;
                if (ownsAppender(*i, i2)) {
                    delete (*i);
                }
              =20
                _ownsAppender.clear();
                _appender.clear();
            }
        }
    }


cheers,
--jakub

=20
=20


> -----Original Message-----
> From: ext Bastiaan Bakker [  <mailto:bas...@li...> =
mailto:bas...@li...]
> Sent: 2. april 2002 22:48
> To: Szymanski Jakub (NET/Copenhagen)
> Cc: log...@li...
> Subject: Re: [Log4cpp-devel] problem with Category::removeAllAppenders
>
>
> Hi Jakub,
>
> This is a known bug (#527467) and a fix has been committed to
> CVS (HEAD
> branch). I intend to release 0.3.1 (containing the fix) later
> this week.
>
> Thanks,
>
> Bastiaan Bakker
> LifeLine Networks bv
>
> Jak...@no... wrote:
>
> >Hi,
> >
> >I run log4cpp on VC6.0 SP5. Version 0.30 + Category and Appender
> >from CVS.
> >
> >I have problem with Category::removeAllAppenders.
> >Version 1.34 (most current in CVS).
> >
> >When I run testCategory (or my simple tests) I have
> >Unhandled exception Access Violation
> >with stack trace:
> >[ ....cut ...]
> >log4cpp::Category::removeAllAppenders() line 152 + 16 bytes
> >main(int 1, char * * 0x004417d0) line 144 + 13 bytes
> >mainCRTStartup() line 338 + 17 bytes
> >KERNEL32! 77f1ba06()
> >
> >
> >There is:
> >    void Category::removeAllAppenders() {
> >        threading::ScopedLock lock(_appenderSetMutex);
> >        {
> >            for (AppenderSet::iterator i =3D _appender.begin();
> >                 i !=3D _appender.end(); i++) {
> >                // found
> >                OwnsAppenderMap::iterator i2;
> >                if (ownsAppender(*i, i2)) {
> >                    delete (*i);
> >                }
> >              =20
> >                _ownsAppender.clear();
> >                _appender.clear();
> >            }
> >        }
> >    }
> >
> >
> >Problem is with delete of current iterator. Acording to specs and
> >good comment in Appender.cpp you can't use iterator after
> deleteing it
> >[
> > Appender::_deleteAllAppenders()
> > --- cut ---
> >            i++; // increment iterator before delete or
> iterator will be invalid.
> >            delete (app);
> >]
> >
> >
> >So I changed code to:
> >    void Category::removeAllAppenders() {
> >        threading::ScopedLock lock(_appenderSetMutex);
> >        {
> >            Appender* app;
> >            AppenderSet::iterator i2;
> >
> >            for (AppenderSet::iterator i =3D _appender.begin();
> >                 i !=3D _appender.end(); ) {
> >                // found
> >                app =3D *i;
> >                i2 =3D i;
> >                i++;
> >
> >                OwnsAppenderMap::iterator i3;
> >                if (ownsAppender(*i2, i3)) {
> >                    delete app;
> >                }
> >             }
> >               =20
> >                _ownsAppender.clear();
> >                _appender.clear();
> >        }
> >    }
> >
> >and it passes testCategory test.
> >
> >cheers,
> >--jakub
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >Log4cpp-devel mailing list
> >Log...@li...
> >  <https://lists.sourceforge.net/lists/listinfo/log4cpp-devel> =
https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
> >
>
>
>
>=20

Re: [Log4cpp-devel] problem with Category::removeAllAppenders

[Bastiaan B. <bas...@li...>]

Hi Jakub,

This is a known bug (#527467) and a fix has been committed to CVS (HEAD 
branch). I intend to release 0.3.1 (containing the fix) later this week.

Thanks,

Bastiaan Bakker
LifeLine Networks bv

Jak...@no... wrote:

>Hi,
>
>I run log4cpp on VC6.0 SP5. Version 0.30 + Category and Appender
>from CVS.
>
>I have problem with Category::removeAllAppenders.
>Version 1.34 (most current in CVS).
>
>When I run testCategory (or my simple tests) I have
>Unhandled exception Access Violation
>with stack trace:
>[ ....cut ...]
>log4cpp::Category::removeAllAppenders() line 152 + 16 bytes
>main(int 1, char * * 0x004417d0) line 144 + 13 bytes
>mainCRTStartup() line 338 + 17 bytes
>KERNEL32! 77f1ba06()
>
>
>There is:
>    void Category::removeAllAppenders() {
>        threading::ScopedLock lock(_appenderSetMutex);
>        {
>            for (AppenderSet::iterator i = _appender.begin();
>                 i != _appender.end(); i++) {
>                // found
>                OwnsAppenderMap::iterator i2;
>                if (ownsAppender(*i, i2)) {
>                    delete (*i);
>                }
>                
>                _ownsAppender.clear();
>                _appender.clear();
>            }
>        }
>    }
>
>
>Problem is with delete of current iterator. Acording to specs and
>good comment in Appender.cpp you can't use iterator after deleteing it
>[
> Appender::_deleteAllAppenders() 
> --- cut ---
>            i++; // increment iterator before delete or iterator will be invalid.
>            delete (app);
>]
>
>
>So I changed code to:
>    void Category::removeAllAppenders() {
>        threading::ScopedLock lock(_appenderSetMutex);
>        {
>            Appender* app;
>            AppenderSet::iterator i2;
>
>            for (AppenderSet::iterator i = _appender.begin();
>                 i != _appender.end(); ) {
>                // found
>                app = *i;
>                i2 = i;
>                i++;
>
>                OwnsAppenderMap::iterator i3;
>                if (ownsAppender(*i2, i3)) {
>                    delete app;
>                }
>             }
>                 
>                _ownsAppender.clear();
>                _appender.clear();
>        }
>    }
>
>and it passes testCategory test.
>
>cheers,
>--jakub
>
>
>
>
>
>
>_______________________________________________
>Log4cpp-devel mailing list
>Log...@li...
>https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>

[Log4cpp-devel] problem with Category::removeAllAppenders

[<Jak...@no...>]

Hi,

I run log4cpp on VC6.0 SP5. Version 0.30 + Category and Appender
from CVS.

I have problem with Category::removeAllAppenders.
Version 1.34 (most current in CVS).

When I run testCategory (or my simple tests) I have
Unhandled exception Access Violation
with stack trace:
[ ....cut ...]
log4cpp::Category::removeAllAppenders() line 152 + 16 bytes
main(int 1, char * * 0x004417d0) line 144 + 13 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77f1ba06()


There is:
    void Category::removeAllAppenders() {
        threading::ScopedLock lock(_appenderSetMutex);
        {
            for (AppenderSet::iterator i =3D _appender.begin();
                 i !=3D _appender.end(); i++) {
                // found
                OwnsAppenderMap::iterator i2;
                if (ownsAppender(*i, i2)) {
                    delete (*i);
                }
               =20
                _ownsAppender.clear();
                _appender.clear();
            }
        }
    }


Problem is with delete of current iterator. Acording to specs and
good comment in Appender.cpp you can't use iterator after deleteing it
[
 Appender::_deleteAllAppenders()=20
 --- cut ---
            i++; // increment iterator before delete or iterator will be =
invalid.
            delete (app);
]


So I changed code to:
    void Category::removeAllAppenders() {
        threading::ScopedLock lock(_appenderSetMutex);
        {
            Appender* app;
            AppenderSet::iterator i2;

            for (AppenderSet::iterator i =3D _appender.begin();
                 i !=3D _appender.end(); ) {
                // found
                app =3D *i;
                i2 =3D i;
                i++;

                OwnsAppenderMap::iterator i3;
                if (ownsAppender(*i2, i3)) {
                    delete app;
                }
             }
                =20
                _ownsAppender.clear();
                _appender.clear();
        }
    }

and it passes testCategory test.

cheers,
--jakub

RE: [Log4cpp-devel] Suggestion: Thread Library

[Bastiaan B. <Bas...@li...>]

Hi Paulo,

I welcome support for any thread library to make log4cpp MT safe. Given =
the currently limited MT primitive requirements of log4cpp it should be =
easy to write an adapter class for GNU Common C++ threading support, =
just like the one for omniORB or Boost.=20
However I do want to make sure that compiling log4cpp with any =
particular thread library is optional: as soon as log4cpp depends on a =
specific library you start to shut out people who cannot or do not want =
to use that library.=20
So I would like to invite you to help improve log4cpp's MT support, but =
please do it in a way that a simple '--with-gnu-common-cpp-threads' =
switch will enable or disable it.

Thanks,

Bastiaan Bakker
=20

> -----Original Message-----
> From: Paulo Pizarro [mailto:pau...@di...]
> Sent: Thursday, March 07, 2002 2:25 PM
> To: log...@li...
> Subject: [Log4cpp-devel] Suggestion: Thread Library
>=20
>=20
> Hello Bastiaan,
>=20
> What do you think about GNU Common C++ library?
>=20
> GNU Common C++ offers support and portable classes for=20
> threading and sockets=20
> for both UNIX (Posix systems with "pthread" support) and the=20
> Windows "Win32"=20
> API. GNU Common C++ uses extensive autoconf macro sets for automatic=20
> detection of various levels of "pthread compliance" in your=20
> target platform=20
> and attempts to adjust itself appropriately. GNU Common C++=20
> has been tested=20
> from time to time with GNU/Linux, FreeBSD, Solaris, and DEC=20
> Tru64 Unix.=20
> Recent work has also been done to help support HP/UX.=20
>=20
> While GNU Common C++ is not directly related to GNU portable=20
> threading (GNU=20
> Pth), it should work with the Pth "pthread emulation" library=20
> at present.=20
> Work is planned to make GNU Common C++ directly support GNU Pth.=20
>=20
> Cheers,
>=20
> Paulo Pizarro
>=20
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>=20

[Log4cpp-devel] Suggestion: Thread Library

[Paulo P. <pau...@di...>]

Hello Bastiaan,

What do you think about GNU Common C++ library?

GNU Common C++ offers support and portable classes for threading and sock=
ets=20
for both UNIX (Posix systems with "pthread" support) and the Windows "Win=
32"=20
API. GNU Common C++ uses extensive autoconf macro sets for automatic=20
detection of various levels of "pthread compliance" in your target platfo=
rm=20
and attempts to adjust itself appropriately. GNU Common C++ has been test=
ed=20
from time to time with GNU/Linux, FreeBSD, Solaris, and DEC Tru64 Unix.=20
Recent work has also been done to help support HP/UX.=20

While GNU Common C++ is not directly related to GNU portable threading (G=
NU=20
Pth), it should work with the Pth "pthread emulation" library at present.=
=20
Work is planned to make GNU Common C++ directly support GNU Pth.=20

Cheers,

Paulo Pizarro

[Log4cpp-devel] 0.3.0 released: work in progress for MT support

[Bastiaan B. <bas...@li...>]

Hi everybody,

I put log4cpp 0.3.0 on SF, which is the first release from the new 
'development' branch. It introduces the first steps for mulithreading 
support.
This release uses omniORB4s omniThread thread abstraction library, 
mainly because at LifeLine we use log4cpp mostly in omniORB bases CORBA 
applications. The used set of MT primitives is rather minimal:
a (non recursive) mutex: log4cpp::threading::Mutex
a scoped lock for the mutex: log4cpp::threading::ScopedLock
a holder for thread local objects: 
log4cpp::threading::ThreadLocalDataHolder<typename T>

It should be rather straightforward to base MT support on other 
threading libraries than omniThreads. A start has been made to implement 
this for Boosts threads, but this has not been integrated yet (help 
wanted!).
Implementations for other libraries are welcome too.

TODOs:
* update of MSVC6 project files
* update of BCB5 project files
* addition other plaforms than Linux and Solaris to BB_CHECK_OMNITHREADS.m4
* more documentation (as always)
* tests
* implementations for other threading libraries, e.g. Boost, Win32 
native, POSIX.

Don't be shy if you can/want to help! :-)

Cheers,

Bastiaan Bakker

[Log4cpp-devel] FYI: log4cpp 0.2 maintainance branch created, multithreading coding started

[Bastiaan B. <Bas...@li...>]

Hi,
=20
Last night I created a branch 'BRANCH_MAINT_0_2' in the CVS repository. =
This is intended for maintainance of all future 0.2.x releases.
The HEAD is now for development of 0.3 and beyond. This means that new  =
features and fixes won't show up in 0.2.x releases anymore, unless =
explicitly merged.=20
If you have CVS write access, please stay on the HEAD branch as much as =
possible and commit fixes to 0.2.x only after testing on HEAD.
The reason for creating this branch now, is that I've finally started =
committing code for multithreading support (see =
include/log4cpp/threading) and MT support is definitely a feature that =
belongs in 0.3 and not 0.2.
Hopefully 0.3 matures quickly enough that we won't need to touch the 0.2 =
branch often anymore.
=20
Cheers,
=20
Bastiaan Bakker
LifeLine Networks bv
=20
=20

Re: [Log4cpp-devel] RE: Log4cpp on OpenVMS

[Tony C. <dra...@as...>]

Hi,

A correction to my earlier's posting.

fsync() actually returns only after the I/O completes.
There's an alternative sync() which returns before the I/O completes.

I think O_SYNC and fsync() should be pretty much the same, with fsync()
doing the file I/O synchronization explicitely.

Tony

Bastiaan Bakker wrote:
> 
> Tony Cheung wrote:
> 
> >Hi Steve and others,
> >
> >First, the changes (if made) will be applied to OpenVMS compilations
> >only. I am not sure if other platforms require the changes.
> >
> >For the disk caching, in order allow other users to "tail -f" on the
> >application log real-time. The OS needs to flush the changes to the disk
> >after each line of the logging. The caching should only be applicable to
> >within a single line of logging, otherwise there would be a delay for
> >the last few lines of logging to show up. BTW, the fsync() returns
> >before the I/O completes.
> >
> >I agree it's a tradeoff between real-time feedback or better disk
> >performance.
> >
> >Ideas?
> >
> >Tony
> >
> 
> This feature may be more generally useful as well. In combination with a
> write cache disabled disk it can provide 'extra safe' logging. Of course
> log4j/log4cpp are still 'non reliable, best effort'  loggers, but this
> may help a bit.
> So I  suggest to add this as a runtime option to FileAppender. Now for
> the implementation,  doe anyone have a good opion on whether to use
> fdatasync() or the O_SYNC open flag?
> 
> Bastiaan

Re: [Log4cpp-devel] RE: Log4cpp on OpenVMS

[Bastiaan B. <bas...@li...>]

Tony Cheung wrote:

>Hi Steve and others,
>
>First, the changes (if made) will be applied to OpenVMS compilations
>only. I am not sure if other platforms require the changes.
>
>For the disk caching, in order allow other users to "tail -f" on the
>application log real-time. The OS needs to flush the changes to the disk
>after each line of the logging. The caching should only be applicable to
>within a single line of logging, otherwise there would be a delay for
>the last few lines of logging to show up. BTW, the fsync() returns
>before the I/O completes. 
>
>I agree it's a tradeoff between real-time feedback or better disk
>performance.
>
>Ideas?
>
>Tony
>

This feature may be more generally useful as well. In combination with a 
write cache disabled disk it can provide 'extra safe' logging. Of course 
log4j/log4cpp are still 'non reliable, best effort'  loggers, but this 
may help a bit.
So I  suggest to add this as a runtime option to FileAppender. Now for 
the implementation,  doe anyone have a good opion on whether to use 
fdatasync() or the O_SYNC open flag?
 
Bastiaan

RE: [Log4cpp-devel] Compiling with sun CC

[Bastiaan B. <Bas...@li...>]

> -----Original Message-----
> From: hel...@ed...=20
> [mailto:hel...@ed...]
> Sent: Friday, February 01, 2002 9:08 PM
> To: Bastiaan Bakker; log...@li...
> Subject: RE: [Log4cpp-devel] Compiling with sun CC
>=20
>=20
> Yeah, that seems to do the trick!
>=20
> Perhaps this could go down into a FAQ or something for
> other people to take advantage of?
>=20

Yes, it definitely should, but I've been to busy/lazy to write one.

> First test ran OK, but the second came up with:
>=20
> CC -DHAVE_CONFIG_H -I. -I. -I../include -I../include    -g -c=20
> Clock.cpp
> "Clock.cpp", line 47: Error: endl is not defined.
> 1 Error(s) detected.
>=20
> some std:: missing, perhaps.
>=20

Hmm, you're right. I thought I got rid of all of them...

> We are thinking about using this library in our software. Has
> anyone run purify on this code to check for memory leaks? Any
> routine on that before you ship new releases?
>=20

Well, I don't have access to Purify myself, so it's not part of the =
release routine. Incidentally other people have checked with Purify, =
BoundsChecker or similar tools. If you like to see this happen within =
the release regime, please volunteer to run Purify and report on the =
release candidates so any leaks can be fixed before the final release...
 =20
> How about connection to the Lumbermill GUI/Log server? I see
> that it's missing a SocketAppender class, so this probably=20
> haven't been tested? Should be easy to add such a class, though?
>=20

AFAIK this has not been tried. However most of the work here is not in =
the socket related stuff (for *nix machines you can already send logs =
through a socket using FileAppender and a socket file descriptor), but =
in writing the data conformant to the Java serialization API. But maybe =
it turns out to be a very simple format, or maybe someone has created a =
nice library to do it for us, I dunno. You're very welcome to contribute =
:-)

> Best regards,
> Helge Fredriksen

Cheers,

Bastiaan Bakker

[Log4cpp-devel] RE: Log4cpp on OpenVMS

[Tony C. <dra...@as...>]

Hi Steve and others,

First, the changes (if made) will be applied to OpenVMS compilations
only. I am not sure if other platforms require the changes.

For the disk caching, in order allow other users to "tail -f" on the
application log real-time. The OS needs to flush the changes to the disk
after each line of the logging. The caching should only be applicable to
within a single line of logging, otherwise there would be a delay for
the last few lines of logging to show up. BTW, the fsync() returns
before the I/O completes. 

I agree it's a tradeoff between real-time feedback or better disk
performance.

Ideas?

Tony

> I am not exactly sure how the OpenVMS file system works, but most file
> systems cache writes in memory before flushing them to disk. This greatly
> increases write performance. I would not (at least in the default case), put
> a fflush or fsync in the code.
> 
> Perhaps an additional method which would allow the application to flush
> write to the disk.
> 
> Steve Ostlind
> PentaSafe Security Technologies
> 713.860.9664
> 
> > -----Original Message-----
> > From:	Tony Cheung [SMTP:dra...@as...]
> > Sent:	Friday, February 01, 2002 4:08 AM
> > To:	log...@li...
> > Subject:	[Log4cpp-devel] Log4cpp on OpenVMS
> > 
> > Hi All,
> > 
> > I'm not sure how many are using the OpenVMS platform here, but I am
> > responsible for the OpenVMS support in log4cpp. (I'm rather new to
> > OpenVMS myself, but I am now building a C/C++ project on it)
> > 
> > I've just found out that in current log4cpp, while the application is
> > logging to a file, other users are not able to see the log file.
> > 
> > After some investigations, I've found we could open the log file in
> > shared mode and in the record mode file format (both OpenVMS specific),
> > so that other users could "tail" on the log file.
> > 
> > fsync() should also be called after evey write, so that other users
> > could see the real-time changes.
> > 
> > Please let me know if it's a good idea to make the changes into CVS, so
> > that I would go ahead and do so.
> > 
> > Tony
> > 
> > P.S. I have subscribed to this mailing list, but somehow I am not
> > receiving anything from it. Hope I am the only one having this problem.
> > 
> > _______________________________________________
> > Log4cpp-devel mailing list
> > Log...@li...
> > https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

RE: [Log4cpp-devel] Compiling with sun CC

[<hel...@ed...>]

Yeah, that seems to do the trick!

Perhaps this could go down into a FAQ or something for
other people to take advantage of?

First test ran OK, but the second came up with:

CC -DHAVE_CONFIG_H -I. -I. -I../include -I../include    -g -c Clock.cpp
"Clock.cpp", line 47: Error: endl is not defined.
1 Error(s) detected.

some std:: missing, perhaps.

We are thinking about using this library in our software. Has
anyone run purify on this code to check for memory leaks? Any
routine on that before you ship new releases?

How about connection to the Lumbermill GUI/Log server? I see
that it's missing a SocketAppender class, so this probably=20
haven't been tested? Should be easy to add such a class, though?

Best regards,
Helge Fredriksen

-----Original Message-----
From: Bastiaan Bakker [mailto:Bas...@li...]
Sent: 1. februar 2002 15:23
To: Fredriksen Helge (4tel); log...@li...
Subject: RE: [Log4cpp-devel] Compiling with sun CC


Hmm, this looks suspiciously like the sun CC compile problems discussed
earlier on this list. Does=20
CC=3DCC CXX=3DCC LD=3D"CC -KPIC" ./configure --disable-static=20
work?

Cheers,

Bastiaan

> -----Original Message-----
> From: hel...@ed...=20
> [mailto:hel...@ed...]
> Sent: Friday, February 01, 2002 12:07 PM
> To: log...@li...
> Subject: [Log4cpp-devel] Compiling with sun CC
>=20
>=20
> Hay there!
>=20
> I've just been trying to compile log4cpp with Sun CC native=20
> compiler (Forte
> 6.2).
> I was not very successful using the configure program for=20
> this: Giving the=20
> arguments "CC=3DCC CXX=3DCC ./configure" produced Makefiles OK,=20
> the lib were
> produced, but when I tried to link it to one of the test=20
> executables, lot's
> of symbols
> didn't get recognized.=20
>=20
> However, I made my own Makefiles which worked fine, I'm=20
> sharing them with
> you in case you want to incorporate this stuff into your make=20
> regime...
>=20
>  <<Makefile.src>>  <<Makefile.test>>=20
> Best regards,
> Helge Fredriksen
>=20

RE: [Log4cpp-devel] Log4cpp on OpenVMS

[Steve O. <s.o...@pe...>]

I am not exactly sure how the OpenVMS file system works, but most file
systems cache writes in memory before flushing them to disk. This greatly
increases write performance. I would not (at least in the default case), put
a fflush or fsync in the code.

Perhaps an additional method which would allow the application to flush
write to the disk.

Steve Ostlind
PentaSafe Security Technologies
713.860.9664

> -----Original Message-----
> From:	Tony Cheung [SMTP:dra...@as...]
> Sent:	Friday, February 01, 2002 4:08 AM
> To:	log...@li...
> Subject:	[Log4cpp-devel] Log4cpp on OpenVMS
> 
> Hi All,
> 
> I'm not sure how many are using the OpenVMS platform here, but I am
> responsible for the OpenVMS support in log4cpp. (I'm rather new to
> OpenVMS myself, but I am now building a C/C++ project on it)
> 
> I've just found out that in current log4cpp, while the application is
> logging to a file, other users are not able to see the log file.
> 
> After some investigations, I've found we could open the log file in
> shared mode and in the record mode file format (both OpenVMS specific),
> so that other users could "tail" on the log file.
> 
> fsync() should also be called after evey write, so that other users
> could see the real-time changes.
> 
> Please let me know if it's a good idea to make the changes into CVS, so
> that I would go ahead and do so.
> 
> Tony
> 
> P.S. I have subscribed to this mailing list, but somehow I am not
> receiving anything from it. Hope I am the only one having this problem.
> 
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

RE: [Log4cpp-devel] Compiling with sun CC

[Bastiaan B. <Bas...@li...>]

Hmm, this looks suspiciously like the sun CC compile problems discussed =
earlier on this list. Does=20
CC=3DCC CXX=3DCC LD=3D"CC -KPIC" ./configure --disable-static=20
work?

Cheers,

Bastiaan

> -----Original Message-----
> From: hel...@ed...=20
> [mailto:hel...@ed...]
> Sent: Friday, February 01, 2002 12:07 PM
> To: log...@li...
> Subject: [Log4cpp-devel] Compiling with sun CC
>=20
>=20
> Hay there!
>=20
> I've just been trying to compile log4cpp with Sun CC native=20
> compiler (Forte
> 6.2).
> I was not very successful using the configure program for=20
> this: Giving the=20
> arguments "CC=3DCC CXX=3DCC ./configure" produced Makefiles OK,=20
> the lib were
> produced, but when I tried to link it to one of the test=20
> executables, lot's
> of symbols
> didn't get recognized.=20
>=20
> However, I made my own Makefiles which worked fine, I'm=20
> sharing them with
> you in case you want to incorporate this stuff into your make=20
> regime...
>=20
>  <<Makefile.src>>  <<Makefile.test>>=20
> Best regards,
> Helge Fredriksen
>=20

[Log4cpp-devel] Compiling with sun CC

[<hel...@ed...>]

Hay there!

I've just been trying to compile log4cpp with Sun CC native compiler =
(Forte
6.2).
I was not very successful using the configure program for this: Giving =
the=20
arguments "CC=3DCC CXX=3DCC ./configure" produced Makefiles OK, the lib =
were
produced, but when I tried to link it to one of the test executables, =
lot's
of symbols
didn't get recognized.=20

However, I made my own Makefiles which worked fine, I'm sharing them =
with
you in case you want to incorporate this stuff into your make regime...

 <<Makefile.src>>  <<Makefile.test>>=20
Best regards,
Helge Fredriksen

[Log4cpp-devel] Log4cpp on OpenVMS

[Tony C. <dra...@as...>]

Hi All,

I'm not sure how many are using the OpenVMS platform here, but I am
responsible for the OpenVMS support in log4cpp. (I'm rather new to
OpenVMS myself, but I am now building a C/C++ project on it)

I've just found out that in current log4cpp, while the application is
logging to a file, other users are not able to see the log file.

After some investigations, I've found we could open the log file in
shared mode and in the record mode file format (both OpenVMS specific),
so that other users could "tail" on the log file.

fsync() should also be called after evey write, so that other users
could see the real-time changes.

Please let me know if it's a good idea to make the changes into CVS, so
that I would go ahead and do so.

Tony

P.S. I have subscribed to this mailing list, but somehow I am not
receiving anything from it. Hope I am the only one having this problem.