log4cpp-devel — technical discussions about the development of log4cpp

Re: [Log4cpp-devel] exception handling on SunOS when using shared log4cpp library

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

Hi Greg,

There have been positive reports about linking log4cpp with newer CVS
revisions of libtool. See the 'linking issues' thread on the 'Open
Discussion' forum last October. 
Unfortunately these C++ link improvements have not been put into a
libtool release and consequently are not in log4cpp yet.

Good luck,

Bastiaan

On Thu, 2003-03-20 at 23:28, Beresnev, Greg wrote:
> $ uname -sr
> SunOS 5.8
> 
> $ cat /var/sadm/softinfo/INST_RELEASE
> OS=Solaris
> VERSION=8
> REV=0
> 
> $ g++ --version
> 2.95.3
> 
> When I compile and use static log4cpp library, all tests on Solaris
> succeed, but when I try to use
> shared version, executing testPriority results in Abort and core being
> dumped:
> 
> g++ -DHAVE_CONFIG_H -I. -I. -I../include -I../include    -g -O2 -Wall
> -pedantic -c testPriority.cpp
> /bin/sh ../libtool --mode=link g++  -g -O2 -Wall -pedantic  -o
> testPriority  testPriority.o ../src/liblog4cpp.la -lnsl -lsocket
> 
> g++ -g -O2 -Wall -pedantic -o .libs/testPriority testPriority.o 
> ../src/.libs/liblog4cpp.so -lnsl -lsocket -R/usr/local/lib
> 
> creating testPriority
> ./testPriority > testPriority.testout 2>&1
> Abort - core dumped
> gmake: *** [testPriority] Error 134
> 
> when I load up the executable and core in gdb, I get:
> 
> $ gdb ./.libs/testPriority core
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "sparc-sun-solaris2.8"...
> Core was generated by `testPriority'.
> Program terminated with signal 6, Abort.
> Reading symbols from
> /export/home/sso/builds/obj/sol5.8/log4cpp/log4cpp/tests/../src/.libs/liblog4cpp.so.1...
> done.
> Loaded symbols for
> /export/home/sso/builds/obj/sol5.8/log4cpp/log4cpp/tests/../src/.libs/liblog4cpp.so.1
> Reading symbols from /usr/lib/libnsl.so.1...done.
> Loaded symbols for /usr/lib/libnsl.so.1
> Reading symbols from /usr/lib/libsocket.so.1...done.
> Loaded symbols for /usr/lib/libsocket.so.1
> Reading symbols from /opt/sfw/lib//libstdc++.so.2.10.0...done.
> Loaded symbols for /opt/sfw/lib//libstdc++.so.2.10.0
> Reading symbols from /usr/lib/libm.so.1...done.
> Loaded symbols for /usr/lib/libm.so.1
> Reading symbols from /usr/lib/libc.so.1...done.
> Loaded symbols for /usr/lib/libc.so.1
> Reading symbols from /usr/lib/libdl.so.1...done.
> Loaded symbols for /usr/lib/libdl.so.1
> Reading symbols from /usr/lib/libmp.so.2...done.
> Loaded symbols for /usr/lib/libmp.so.2
> Reading symbols from
> /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1...done.
> Loaded symbols for /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
> #0  0xff11a034 in _libc_kill () from /usr/lib/libc.so.1
> 
> (gdb) bt
> #0  0xff11a034 in _libc_kill () from /usr/lib/libc.so.1
> #1  0xff0b512c in abort () from /usr/lib/libc.so.1
> #2  0xff22231c in __default_terminate () from
> /opt/sfw/lib//libstdc++.so.2.10.0
> #3  0xff22234c in __terminate () from
> /opt/sfw/lib//libstdc++.so.2.10.0
> #4  0xff222e64 in throw_helper (eh=0xff254a64, pc=0xff362b3b,
> my_udata=0xffbef620, offset_p=0xffbef61c)
>    from /opt/sfw/lib//libstdc++.so.2.10.0
> #5  0xff22306c in __throw () from /opt/sfw/lib//libstdc++.so.2.10.0
> #6  0xff362b3c in log4cpp::Priority::getPriorityValue
> (priorityName=@0xffbef940) at Priority.cpp:65
> #7  0x112d8 in main (argc=138240, argv=0xffbef9bc) at
> testPriority.cpp:13
> 
> like I mentioned before, this problem didn't exist when I used static
> version of log4cpp library. After doing some newsgroup
> 
> searching, I've found the following: 
> 
> "It turns out that libtool uses "ld" instead of "g++" to create shared
> libraries. This causes problems for packages like cppunit that rely on
> libtool to create shared libraries that are written in C++. The g++
> linker automatically adds special prolog code to the .so that takes
> care of passing exceptions across the shared library interface. If you
> link the library with "ld", then the prolog code is not added and
> exceptions cause an abort if they reach a point in the call stack that
> crosses out of the current shared library. This is really a bug in the
> libtool distributed with C++ libraries. The simplest work around is to
> relink the library using g++ instead of ld. Perhaps the maintainers of
> libtool will release a patch that addresses this issue."
> 
> I then had a look at the libtool website, and there found this:
> "Creating libraries of C++ code should be a fairly straightforward
> process, because its object files differ from C ones in only three
> ways: 
> 
>         Because of name mangling, C++ libraries are only usable by the
>         C++ compiler that created them. This decision was made by the
>         designers of C++ in order to protect users from conflicting
>         implementations of features such as constructors, exception
>         handling, and RTTI. 
>         
>         On some systems, the C++ compiler must take special actions
>         for the dynamic linker to run dynamic (i.e., run-time)
>         initializers. This means that we should not call `ld' directly
>         to link such libraries, and we should use the C++ compiler
>         instead. 
>         
>         C++ compilers will link some Standard C++ library in by
>         default, but libtool does not know which are these libraries,
>         so it cannot even run the inter-library dependence analyzer to
>         check how to link it in. Therefore, running `ld' to link a C++
>         program or library is deemed to fail. However, running the C++
>         compiler directly may lead to problems related with
>         inter-library dependencies. 
>         
>         
> The conclusion is that libtool is not ready for general use for C++
> libraries. You should avoid any global or static variable
> initializations that would cause an "initializer element is not
> constant" error if you compiled them with a standard C compiler"
> 
> I'm just wondering what the most appropriate solution would be under
> the circumstances ... modifying 'configure' to ensure
> 
> C++ compiler (and not ld) gets used for creation of shared C++
> libraries?
> 
> Greg
-- 
Bastiaan Bakker <bas...@li...>

[Log4cpp-devel] exception handling on SunOS when using shared log4cpp library

[Beresnev, G. <GRE...@ca...>]

$ uname -sr
SunOS 5.8

$ cat /var/sadm/softinfo/INST_RELEASE
OS=3DSolaris
VERSION=3D8
REV=3D0

$ g++ --version
2.95.3

When I compile and use static log4cpp library, all tests on Solaris =
succeed, but when I try to use
shared version, executing testPriority results in Abort and core being =
dumped:

g++ -DHAVE_CONFIG_H -I. -I. -I../include -I../include    -g -O2 -Wall =
-pedantic -c testPriority.cpp
/bin/sh ../libtool --mode=3Dlink g++  -g -O2 -Wall -pedantic  -o =
testPriority  testPriority.o ../src/liblog4cpp.la -lnsl -lsocket
g++ -g -O2 -Wall -pedantic -o .libs/testPriority testPriority.o  =
../src/.libs/liblog4cpp.so -lnsl -lsocket -R/usr/local/lib
creating testPriority
./testPriority > testPriority.testout 2>&1
Abort - core dumped
gmake: *** [testPriority] Error 134

when I load up the executable and core in gdb, I get:

$ gdb ./.libs/testPriority core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you =
are
welcome to change it and/or distribute copies of it under certain =
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for =
details.
This GDB was configured as "sparc-sun-solaris2.8"...
Core was generated by `testPriority'.
Program terminated with signal 6, Abort.
Reading symbols from =
/export/home/sso/builds/obj/sol5.8/log4cpp/log4cpp/tests/../src/.libs/lib=
log4cpp.so.1...
done.
Loaded symbols for =
/export/home/sso/builds/obj/sol5.8/log4cpp/log4cpp/tests/../src/.libs/lib=
log4cpp.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libsocket.so.1...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /opt/sfw/lib//libstdc++.so.2.10.0...done.
Loaded symbols for /opt/sfw/lib//libstdc++.so.2.10.0
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libmp.so.2...done.
Loaded symbols for /usr/lib/libmp.so.2
Reading symbols from =
/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1...done.
Loaded symbols for /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
#0  0xff11a034 in _libc_kill () from /usr/lib/libc.so.1

(gdb) bt
#0  0xff11a034 in _libc_kill () from /usr/lib/libc.so.1
#1  0xff0b512c in abort () from /usr/lib/libc.so.1
#2  0xff22231c in __default_terminate () from =
/opt/sfw/lib//libstdc++.so.2.10.0
#3  0xff22234c in __terminate () from /opt/sfw/lib//libstdc++.so.2.10.0
#4  0xff222e64 in throw_helper (eh=3D0xff254a64, pc=3D0xff362b3b, =
my_udata=3D0xffbef620, offset_p=3D0xffbef61c)
   from /opt/sfw/lib//libstdc++.so.2.10.0
#5  0xff22306c in __throw () from /opt/sfw/lib//libstdc++.so.2.10.0
#6  0xff362b3c in log4cpp::Priority::getPriorityValue =
(priorityName=3D@0xffbef940) at Priority.cpp:65
#7  0x112d8 in main (argc=3D138240, argv=3D0xffbef9bc) at =
testPriority.cpp:13

like I mentioned before, this problem didn't exist when I used static =
version of log4cpp library. After doing some newsgroup
searching, I've found the following:=20

"It turns out that libtool uses "ld" instead of "g++" to create shared =
libraries. This causes problems for packages like cppunit that rely on =
libtool to create shared libraries that are written in C++. The g++ =
linker automatically adds special prolog code to the .so that takes care =
of passing exceptions across the shared library interface. If you link =
the library with "ld", then the prolog code is not added and exceptions =
cause an abort if they reach a point in the call stack that crosses out =
of the current shared library. This is really a bug in the libtool =
distributed with C++ libraries. The simplest work around is to relink =
the library using g++ instead of ld. Perhaps the maintainers of libtool =
will release a patch that addresses this issue."
I then had a look at the libtool website, and there found this:
"Creating libraries of C++ code should be a fairly straightforward =
process, because its object files differ from C ones in only three ways: =

	Because of name mangling, C++ libraries are only usable by the C++ =
compiler that created them. This decision was made by the designers of =
C++ in order to protect users from conflicting implementations of =
features such as constructors, exception handling, and RTTI.=20
	On some systems, the C++ compiler must take special actions for the =
dynamic linker to run dynamic (i.e., run-time) initializers. This means =
that we should not call `ld' directly to link such libraries, and we =
should use the C++ compiler instead.=20
	C++ compilers will link some Standard C++ library in by default, but =
libtool does not know which are these libraries, so it cannot even run =
the inter-library dependence analyzer to check how to link it in. =
Therefore, running `ld' to link a C++ program or library is deemed to =
fail. However, running the C++ compiler directly may lead to problems =
related with inter-library dependencies.=20
The conclusion is that libtool is not ready for general use for C++ =
libraries. You should avoid any global or static variable =
initializations that would cause an "initializer element is not =
constant" error if you compiled them with a standard C compiler"
I'm just wondering what the most appropriate solution would be under the =
circumstances ... modifying 'configure' to ensure
C++ compiler (and not ld) gets used for creation of shared C++ =
libraries?

Greg

[Log4cpp-devel] OT: Request for Guidance

[J. S. A. <js...@te...>]

Greetings,

I hope I am not bothering anyone with this request, but Thomas was very
kind to reply to my last query, and I thought I would try again.  If
this request is too far off-base, I apologise.  I am new at C++
programming, but have a fair background with Java.  I am using log4cpp
to provide logging capabilities for a file parser I am writing (seems
obvious so far, yes!).  My question concerns Makefiles and checking for
the existence of the log4cpp library when running ./configure. 
Basically, I am wondering how this is done, and how I can optionally
enable the logging portions of my code based on this check.  If anyone
could offer a small bit of advice, or point me towards a website or
other information archive, I would greatly appreciate it.  Thanks again,
and sorry for the lack of relevance to this devel list.

Best Regards,

Scott 

Re: [Log4cpp-devel] Problem Using log4cpp 0.3.4b

[J. S. A. <js...@te...>]

On Mon, 2003-03-17 at 00:37, Thomas Maier wrote:
> When asking such questions its best to include the program you tried to
> compile or even better an example as small as possible but still
> reproducing the same error.  Fortunately this one seems like an easy one
> (for those who know :)).  You're using Category's copy constructor which
> is private.  That is, you can't write something like
> 
> Category cat = Category::getInstance("some.name");
> 
> because this tries to take the object (reference) i returned by
> getInstance() and construct a new oject cat from this object i, i.e.
> this operation uses the copy constructor.  Instead write
> 
> Category& cat = Category::getInstance("some.name");
> 
> (note the & to say "cat is a reference to a Category object).  BTW IIRC
> this question has already been answered either on this list or in one of
> the forums.
> 
> HTH, Thomas.

Thanks very much for the response (and the advice) - this was indeed the
problem.  Thanks again!

Scott

Re: [Log4cpp-devel] Problem Using log4cpp 0.3.4b

[Thomas M. <Tho...@un...>]

On Mon, 2003-03-17 at 01:26, J. Scott Amort wrote:
> Hi,
> 
> My apologies for posting this to the devel list, but I can't seem to
> find a users list.  I hope someone might take the time to help me out.
> 
> When I try to compile a program using log4cpp 0.3.4b that includes
> "Category.hh", I get the following error:
> 
> /usr/local/include/log4cpp/Category.hh: In function `int main(int,
> char**)':
> /usr/local/include/log4cpp/Category.hh:623:
> `log4cpp::Category::Category(const
>    log4cpp::Category&)' is private
> main.cc:33: within this context

When asking such questions its best to include the program you tried to
compile or even better an example as small as possible but still
reproducing the same error.  Fortunately this one seems like an easy one
(for those who know :)).  You're using Category's copy constructor which
is private.  That is, you can't write something like

Category cat = Category::getInstance("some.name");

because this tries to take the object (reference) i returned by
getInstance() and construct a new oject cat from this object i, i.e.
this operation uses the copy constructor.  Instead write

Category& cat = Category::getInstance("some.name");

(note the & to say "cat is a reference to a Category object).  BTW IIRC
this question has already been answered either on this list or in one of
the forums.

HTH, Thomas.

> 
> I'm running on a RH8.1 (Phoebe) box with gcc (GCC) 3.2.1 20021207 (Red
> Hat Linux 8.0 3.2.1-2).  Any ideas?  Thanks.
> 
> Scott
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
-- 
Thomas Maier (Tho...@un...)

[Log4cpp-devel] Problem Using log4cpp 0.3.4b

[J. S. A. <js...@te...>]

Hi,

My apologies for posting this to the devel list, but I can't seem to
find a users list.  I hope someone might take the time to help me out.

When I try to compile a program using log4cpp 0.3.4b that includes
"Category.hh", I get the following error:

/usr/local/include/log4cpp/Category.hh: In function `int main(int,
char**)':
/usr/local/include/log4cpp/Category.hh:623:
`log4cpp::Category::Category(const
   log4cpp::Category&)' is private
main.cc:33: within this context

I'm running on a RH8.1 (Phoebe) box with gcc (GCC) 3.2.1 20021207 (Red
Hat Linux 8.0 3.2.1-2).  Any ideas?  Thanks.

Scott

[Log4cpp-devel] Remote logging

[Thomas M. <Tho...@un...>]

Hi gurus,

yesterday I had a look at this project and first thing I unfortunately
noticed was that a SocketAppender is missing.  I also browsed through
the CVS and did not find anything.  I also saw one or two RFEs and I
think one or two postings requesting one so I really guess there is none
:).  I'd just like my logging to go somewhere else on screen.  I quickly
thought of some options I have:

I could use "tail -f" but somehow I don't like the "lag".

Then I could open another xterm, get the tty and tell a FileAppender to
log there.  But then again different xterms get different ttys and I
don't wanna hack all my config files when this information changes. 
Btw, is there a way to tell an xterm the tty to use?

Then I could use a fifo, tell a FileAppender to log there.  This works
fine if I have an xterm open with a "cat /tmp/fifo".  But of course it
sucks when I don't have it running because the open() call in
FileAppender blocks.  Of course this could be solved with an O_NONBLOCK
but open flags do not seem to be configurable (I looked at
PropertyConfiguratorImpl.cpp).

So I quickly hacked a SocketAppender which sends logging output (albeit
no serialized LoggingEvents due to obviuos reasons) to a socket and a
little program I called sockcat which just dumps everything read from a
socket (btw, does netcat have an option to "listen forever"?  besides
starting it in an endless loop?).  This works but of course this is also
not "property configurable".

So I could waste^H^H^H^H^H invest some creative energy here.  Would this
be welcome and appreciated?  Or, even better, do you know a quick
solution to the above?

advTHANKSance and regards, Thomas.

-- 
Thomas Maier (Tho...@un...)

[Log4cpp-devel] RollingFileAppender: added maxFileAge

[Scott M <sm...@ya...>]

I couldn't stand that RollingFileAppender didn't roll based on time, so I
added it. Turned out to only be a few lines of code.

Basically it allows you to specify how often, in minutes, you want your log
rotated:

log4j.appender.A1.maxFileAge=5

will roll every 5 minutes.

Assuming you have it enabled (set to zero for no time-based rolling), the
per-log event cost is a single time() call and a compare.

Has someone already done this? Seems too trivial to have been left out.

- Scott

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

[Log4cpp-devel] boost threads with STLport build for MSVC

[David R. <dre...@mo...>]

Hi,

I've added an implementation for boost threads (version 1.28.0) to the
CVS. This has only been tested under MSVC6 when boost was compiled using
STLport 4.5.3.

There is a new MSVC project file that enables building this version,
along with some of the tests. See the file readme.txt at
log4cpp\msvc6\log4cppDLL_stlport_boost for some more details.

Regards,

David Resnick
MobileSpear Inc.

[Log4cpp-devel] Pacth: getAllAppenders to return a vector

[Dirk L. <di...@no...>]

Hi,

attached is a patch for the current CVS (03.03.2003) to fix the problem 
with the getAllAppenders returning a set<>

The patch changes the return value of getAllApenders to return a 
vector<Appender*> like in getCurrentCategories.


There a three more changes contained in the patch:

- put abort into the ProtabilityIpl.hh since it is not in the std 
namespace on WIN32 systems

- added a getFilename method to the FileAppender, that returns the 
filename for the Appender

- added a static getAllAppenders method to the Appender class. This one 
does the same as the getAllAppenders function in the Category class, 
except that it returns all registered appenders.


Dirk

Re: [Log4cpp-devel] Thread safe log4cpp usage ?

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

On Mon, 2003-03-03 at 09:09, Amit V Garde wrote:
> I'm planning to use log4cpp 0.3.4b in a multithreaded setting (on Solaris with
> g++ 3.x and on Win 2K server with MS VC++ 6.0) and I had the following 
> questions regarding thread safety and the relationship between Categories and
> Appenders.
> 
> Is doing the following thread safe by default or does explicit synchronization
> need to be provided by the code using log4cpp ? 
> 
> 1. Multiple threads logging using the same Category object
> 

Is thread safe, even if threading support is not enabled. Note that in
that case on Win32 systems, log messages may become intertwined.

> 2. Multiple FileAppenders or RollingFileAppenders writing to the same 
>    underlying file (possibly from different threads) ?

This may lead to intertwined log messages if file writes on your OS
aren't atomic. In most cases you can avoid this, by sharing the
FileAppender, rather than the underlying file.
   
> 
> If I need to provide synchronization, are there any guidelines regarding 
> what to lock and where etc for minimizing the performance hit ?
> 
> Also, is it okay/advisable to set the same Appender for multiple Category 
> objects (again in a multithreaded setting) ?

Using the same Appender for multiple Categories is OK. If it doesn't
work, that definitively is consider a bug.

> 
> Apologies if this is not the right place to ask usage related questions. Could
> someone point me somewhere that is appropriate if thuis is so ?

Well, officially this is the 'development' mailing list. But since the
traffic is so low and there isn't a 'users' mailing list, I don't mind,
and I assume the other list members don't mind either. 

Bastiaan

> 
> Thanks for any advice...
> 
> Amit
> -------------------------------------------------------------------------------
> | Amit V. Garde      | am...@pe... | +91-20-567-8900 x517           |
> | Persistent Systems | Bhageerath,402 Senapati Bapat Road,Pune 411 016, India |
> -------------------------------------------------------------------------------
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] Thread safe log4cpp usage ?

[Amit V G. <am...@pe...>]

I'm planning to use log4cpp 0.3.4b in a multithreaded setting (on Solaris with
g++ 3.x and on Win 2K server with MS VC++ 6.0) and I had the following 
questions regarding thread safety and the relationship between Categories and
Appenders.

Is doing the following thread safe by default or does explicit synchronization
need to be provided by the code using log4cpp ? 

1. Multiple threads logging using the same Category object

2. Multiple FileAppenders or RollingFileAppenders writing to the same 
   underlying file (possibly from different threads) ?

If I need to provide synchronization, are there any guidelines regarding 
what to lock and where etc for minimizing the performance hit ?

Also, is it okay/advisable to set the same Appender for multiple Category 
objects (again in a multithreaded setting) ?

Apologies if this is not the right place to ask usage related questions. Could
someone point me somewhere that is appropriate if thuis is so ?

Thanks for any advice...

Amit
-------------------------------------------------------------------------------
| Amit V. Garde      | am...@pe... | +91-20-567-8900 x517           |
| Persistent Systems | Bhageerath,402 Senapati Bapat Road,Pune 411 016, India |
-------------------------------------------------------------------------------

Re: [Log4cpp-devel] getAllAppenders fail on Win32 with log4cpp as DLL

[Aaron I. <ai...@ya...>]

No real standard but "-Naur" seems to be preferred.
-Aaron
 Dirk Luetjens <di...@no...> wrote:A question and an answer: As usual after finding the error, explaning it 
to others one also finds the right words to search the net for 
solutions. I found two MSDN articles describing the problem:

---
http://support.microsoft.com/default.aspx?scid=KB;en-us;q172396

SYMPTOMS
When accessing an STL object created in one DLL or EXE through a pointer 
or reference in a different DLL or EXE, you may experience an access 
violation or other serious program errors including the appearance of 
data corruption or data loss.

---
http://support.microsoft.com/default.aspx?scid=kb;EN-US;168958


SUMMARY
This article demonstrates how to:

* Export an instantiation of a Standard Template Library (STL) class.
* Export a class that contains a data member that is an STL object.

Note that you may not export a generalized template. The template must 
be instantiated; that is, all of the template parameters must be 
supplied and must be completely defined types at the point of 
instantiation. For instance "stack;" instantiates the STL stack 
class. The instantiation forces all members of class stack to be 
generated.

Also note that some STL containers (map, set, queue, list, deque) cannot 
be exported. Please refer to the More Information section to follow for 
a detailed explanation.

... a little later ...
The only STL container that can currently be exported is vector.
...

---

The bottom line is: getAllAppenders _must_ generate a std::vector from 
the std::set like getCurrentCategories() to safely export the list of 
appenders.

I would like to give provide you with a patch for this change. Do you 
prefer specific parameters for the diff command?

Dirk



Dirk Luetjens wrote:
> Hi,
> 
> today I had a strange problem with the Categroy::getAllAppenders () 
> function. I'm writing a small gui dialog to customize the logging during 
> the execution of the program. Right now I can edit the categories with 
> the vector returned from getCurrentCategories (). I wanted to display 
> also the list of attached appenders so I asked for the AppenderSet via 
> the function getAllAppenders (). But the returned set is not valid, 
> since the implementation of the _Tree used in the std::set contains a 
> static _Nil node, which is not the same in the process and in the DLL.
> As a result when I try to iterate the returned set I get an invalid 
> AppenderSet::end () iterator and the iteration continues until the 
> software crashes.
> 
> Perhaps as little longer description: the STL implementation of the 
> std::set in Microsoft uses a std::_Tree. The std::_Tree maintains one 
> static _Nil and one static _Nilrefs member, that is used to mark the 
> ends in the trees. This _Nil is used in within all _Trees with the same 
> template arguments. Compiling log4cpp as a DLL will result in having one 
> static instance of these to members within the DLL, that are not the 
> same static instances of theses members in the Application. So copying 
> the AppenderSet within the context of the DLL will use the DLLs instance 
> of the _Nil pointer to mark the ends in the _Tree. But iterating through 
> the std::set within the application context will result in the usage of 
> a different _Nil element. So the iteration through the _Tree will never 
> end, since the end of the _Tree will never match the _Nil element.
> 
> 
> Any ideas how to circumvent the problem?




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Log4cpp-devel mailing list
Log...@li...
https://lists.sourceforge.net/lists/listinfo/log4cpp-devel


---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more

Re: [Log4cpp-devel] getAllAppenders fail on Win32 with log4cpp as DLL

[Dirk L. <di...@no...>]

A question and an answer: As usual after finding the error, explaning it 
to others one also finds the right words to search the net for 
solutions. I found two MSDN articles describing the problem:

---
http://support.microsoft.com/default.aspx?scid=KB;en-us;q172396

SYMPTOMS
When accessing an STL object created in one DLL or EXE through a pointer 
or reference in a different DLL or EXE, you may experience an access 
violation or other serious program errors including the appearance of 
data corruption or data loss.

---
http://support.microsoft.com/default.aspx?scid=kb;EN-US;168958


SUMMARY
This article demonstrates how to:

     * Export an instantiation of a Standard Template Library (STL) class.
     * Export a class that contains a data member that is an STL object.

Note that you may not export a generalized template. The template must 
be instantiated; that is, all of the template parameters must be 
supplied and must be completely defined types at the point of 
instantiation. For instance "stack<int>;" instantiates the STL stack 
class. The instantiation forces all members of class stack<int> to be 
generated.

Also note that some STL containers (map, set, queue, list, deque) cannot 
be exported. Please refer to the More Information section to follow for 
a detailed explanation.

... a little later ...
The only STL container that can currently be exported is vector.
...

---

The bottom line is: getAllAppenders _must_ generate a std::vector from 
the std::set like getCurrentCategories() to safely export the list of 
appenders.

I would like to give provide you with a patch for this change. Do you 
prefer specific parameters for the diff command?

Dirk



Dirk Luetjens wrote:
> Hi,
> 
> today I had a strange problem with the Categroy::getAllAppenders () 
> function. I'm writing a small gui dialog to customize the logging during 
> the execution of the program. Right now I can edit the categories with 
> the vector returned from getCurrentCategories (). I wanted to display 
> also the list of attached appenders so I asked for the AppenderSet via 
> the function getAllAppenders (). But the returned set is not valid, 
> since the implementation of the _Tree used in the std::set contains a 
> static _Nil node, which is not the same in the process and in the DLL.
> As a result when I try to iterate the returned set I get an invalid 
> AppenderSet::end () iterator and the iteration continues until the 
> software crashes.
> 
> Perhaps as little longer description: the STL implementation of the 
> std::set in Microsoft uses a std::_Tree. The std::_Tree maintains one 
> static _Nil and one static _Nilrefs member, that is used to mark the 
> ends in the trees. This _Nil is used in within all _Trees with the same 
> template arguments. Compiling log4cpp as a DLL will result in having one 
> static instance of these to members within the DLL, that are not the 
> same static instances of theses members in the Application. So copying 
> the AppenderSet within the context of the DLL will use the DLLs instance 
> of the _Nil pointer to mark the ends in the _Tree. But iterating through 
> the std::set within the application context will result in the usage of 
> a different _Nil element. So the iteration through the _Tree will never 
> end, since the end of the _Tree will never match the _Nil element.
> 
> 
> Any ideas how to circumvent the problem?

[Log4cpp-devel] getAllAppenders fail on Win32 with log4cpp as DLL

[Dirk L. <di...@no...>]

Hi,

today I had a strange problem with the Categroy::getAllAppenders () 
function. I'm writing a small gui dialog to customize the logging during 
the execution of the program. Right now I can edit the categories with 
the vector returned from getCurrentCategories (). I wanted to display 
also the list of attached appenders so I asked for the AppenderSet via 
the function getAllAppenders (). But the returned set is not valid, 
since the implementation of the _Tree used in the std::set contains a 
static _Nil node, which is not the same in the process and in the DLL.
As a result when I try to iterate the returned set I get an invalid 
AppenderSet::end () iterator and the iteration continues until the 
software crashes.

Perhaps as little longer description: the STL implementation of the 
std::set in Microsoft uses a std::_Tree. The std::_Tree maintains one 
static _Nil and one static _Nilrefs member, that is used to mark the 
ends in the trees. This _Nil is used in within all _Trees with the same 
template arguments. Compiling log4cpp as a DLL will result in having one 
static instance of these to members within the DLL, that are not the 
same static instances of theses members in the Application. So copying 
the AppenderSet within the context of the DLL will use the DLLs instance 
of the _Nil pointer to mark the ends in the _Tree. But iterating through 
the std::set within the application context will result in the usage of 
a different _Nil element. So the iteration through the _Tree will never 
end, since the end of the _Tree will never match the _Nil element.


Any ideas how to circumvent the problem?

Thanks
Dirk

RE: [Log4cpp-devel] boost threads

[David R. <dre...@mo...>]

Hi Bastiaan,

OK, I'm already on it.=20

About something in BoostThreads.hh. I was wondering where the following =
line compiles:

typedef template<typename T> class boost::thread_specific_ptr
            ThreadLocalDataHolder;

MSVC6 won't compile it, and the only solution I've found is to wrap =
boost::thread_specific_ptr in a new class. This seems to depend on a =
proposed addition to the C++ spec, "typedef templates".

Regards,

David Resnick
MobileSpear Inc.

-----Original Message-----
From: Bastiaan Bakker [mailto:bas...@li...]=20
Sent: Tuesday, February 11, 2003 00:35
To: David Resnick
Cc: log...@li...
Subject: Re: [Log4cpp-devel] boost threads

Hi David,

Please go ahead. When I first added threading support I looked at boost
threads and added BoostThreads.hh as a rough. Then, I didn't look
further into using boost and never did attempt to make it work.=20
So please fix it as you see fit.=20

Regards,

Bastiaan


On Mon, 2003-02-10 at 15:12, David Resnick wrote:
> Hi,
>=20
> Is anyone compiling with this? Which version of boost? I=A2ve tried
> compiling using boost 1.28.0 and there are a number of problems. I
> would like to fix it, but I don=A2t want to break anyones build.
>=20
> Please let me know if you are using this.
>=20
> Regards,
>=20
> David Resnick
>=20
> MobileSpear Inc.
--=20
Bastiaan Bakker <bas...@li...>

Re: [Log4cpp-devel] boost threads

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

Hi David,

Please go ahead. When I first added threading support I looked at boost
threads and added BoostThreads.hh as a rough. Then, I didn't look
further into using boost and never did attempt to make it work.=20
So please fix it as you see fit.=20

Regards,

Bastiaan


On Mon, 2003-02-10 at 15:12, David Resnick wrote:
> Hi,
>=20
> Is anyone compiling with this? Which version of boost? I=A2ve tried
> compiling using boost 1.28.0 and there are a number of problems. I
> would like to fix it, but I don=A2t want to break anyones build.
>=20
> Please let me know if you are using this.
>=20
> Regards,
>=20
> David Resnick
>=20
> MobileSpear Inc.
--=20
Bastiaan Bakker <bas...@li...>

[Log4cpp-devel] boost threads

[David R. <dre...@mo...>]

Hi,

Is anyone compiling with this? Which version of boost? I've tried
compiling using boost 1.28.0 and there are a number of problems. I would
like to fix it, but I don't want to break anyones build.

Please let me know if you are using this.

Regards,

David Resnick
MobileSpear Inc.

[Log4cpp-devel] OStringStream used in Layout causing problem

[Betty G. <bet...@do...>]

Dear all,

I'm having some problems with log4cpp when my C++ codes is being used in JNI. I'm developing my codes in RH 7.2.

The implementation of JNI is that I'm supposed to merge all my C++ codes into one .so shared library and JNI will load the library and then call the respective native methods.

My codes works fine without JNI implementation, it runs well with logging and all. 

The problem starts when I build a shared library to be accessed by JNI. The compiling is okay, but when I try to run the JNI. JVM bombs.

I tried tracing down the problem and found that the problem is due to the use of ostringstream in BasicLayout.cpp (which I'm currently using). I did a fix by changing the ostringstreams operations to sprintfs. 

But I still don't understand why ostringstream is causing the JVM errors. Could it be due to a memory leak or ?? 

It is not a good way to just change the ostringstream operations to sprintfs. Maybe there's something else need to be done to the ostringstream instances so that it won't cause these jvm errors?

Can someone please enlighten me?

Many thanks.

regards,
Betty
-- 
_______________________________________________
Get your free email from www.doramail.com with 30 Megs of disk space in webhosting and e-mail storage!


Powered by Outblaze

Re: [Log4cpp-devel] Priority class not exported to DLL?

[Aaron I. <ai...@ya...>]

Hi Steve,

That bug fix is in the CVS repository as of 11/20/02.  It didn't make
it into the most recent release, but you'll see it in the next one.

-Aaron

--- Steve Smith <ste...@ad...> wrote:
> Hi,
> 
> Compiling under BCB6 (from the BCB5 project) the
> classlog4cpp::Priority
> isn't exported to the DLL.  Adding LOG4CPP_EXPORT to the class
> appears to
> work fine.
> 
> Is there a particular reason why this was omitted?  This in 0.2.7,
> but
> appears to be the same in the latest beta?
> 
> Thanks,
> Steve
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security
> issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Log4cpp-devel] Priority class not exported to DLL?

[Steve S. <ste...@ad...>]

Hi,

Compiling under BCB6 (from the BCB5 project) the classlog4cpp::Priority
isn't exported to the DLL.  Adding LOG4CPP_EXPORT to the class appears to
work fine.

Is there a particular reason why this was omitted?  This in 0.2.7, but
appears to be the same in the latest beta?

Thanks,
Steve

[Log4cpp-devel] Win95 build failure

[Beresnev, G. <GRE...@ca...>]

hi, my log4cpp build fails on Windows95 from time to time, with the =
following being recorded in the log:
-------------------------------------------------------------------------=
-------------------------------

cd c:/sso/head.bld/sso-1/95/obj/win95/log4cpp/log4cpp ; unset ECHO ; =
LD=3Dlink CC=3D"c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2" =
CXX=3D"c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2"  CFLAGS=3D"/MD /O2  =
-DWIN32 -D_WIN32 -DMSWIN -DWINVER=3D0x0400 -D_WIN32_WINNT=3D0x0400 =
-pt,/W3 -pt,/G5 -pt,/GX" CPPFLAGS=3D"/MD /O2  -DWIN32 -D_WIN32 -DMSWIN =
-DWINVER=3D0x0400 -D_WIN32_WINNT=3D0x0400 -pt,/W3 -pt,/G5 -pt,/GX" =
MAKEFLAGS=3D MAKE=3D"gmake --unix --no-print-directory" =
TESTCONFIG_LIBS=3D"wsock32.lib" ./configure --disable-debug =
--disable-doxygen --with-threads=3Dnt --disable-shared --without-pic
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether gmake --unix --no-print-directory 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... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking for gcc... c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2
checking for C compiler default output... conftest.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... .exe
checking for object suffix... o
checking whether we are using the GNU C compiler... no
checking whether c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2 accepts -g... =
yes
checking for non-GNU ld... link
checking if the linker (link) is GNU ld... no
checking for link 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... file_magic file format =
pei*-i386(.*architecture: i386)?
checking command to parse /usr/bin/nm -B output... failed
checking how to run the C preprocessor... =
c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2 -E
checking for dlfcn.h... no
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2 option to produce =
PIC... -DDLL_EXPORT
checking if c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2 PIC flag =
-DDLL_EXPORT works... yes
checking if c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2 static flag  =
works... yes
checking if c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2 supports -c -o =
file.o... yes
checking if c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2 supports -c -o =
file.lo... no
checking whether the linker (link) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking if libtool supports shared libraries... yes
creating libtool
checking for a BSD compatible install... /usr/bin/install -c
checking whether gmake --unix --no-print-directory sets ${MAKE}... =
(cached) yes
checking whether we are using the GNU C++ compiler... no
checking whether c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2 accepts -g... =
no
checking how to run the C++ preprocessor... =
c:/sso/head.bld/sso-1/95/sso/mk/gcc2cl2 -E
checking for unistd.h... no
checking for io.h... yes
checking for int64_t... no
checking whether the compiler implements namespaces... no
checking whether the compiler has stringstream... no
checking for working snprintf... no
checking for syslog... no
checking for gettimeofday... no
checking for ftime... no
checking for strcasecmp... no
checking for stricmp... no
checking for socket in -lsocket... no
checking for gethostbyname in -lnsl... no
creating log4cpp-config - generic 0.2.7 of log4cpp
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
creating include/log4cpp/config.h - prefix LOG4CPP for include/config.h =
defines
/* automatically generated CVS/ bcb5/ config/ debian/ doc/ include/ m4/ =
msvc6/ openvms/ src
cd c:/sso/head.bld/sso-1/95/obj/win95/log4cpp/log4cpp ; gmake --unix =
--no-print-directory MAKEFLAGS=3D
cd . && aclocal
cd . && automake --gnu --include-deps Makefile
Makefile.am:1: DOC does not appear in AM_CONDITIONAL
gmake[3]: *** [Makefile.in] Error 1
gmake[2]: *** [c:/sso/head.bld/sso-1/95/obj/win95/log4cpp/.configured] =
Error 2
gmake[1]: *** [build] Error 1
gmake: *** [all] Error 2
ERROR: Operation failed.


But most of the time this doesn't occur. Was wondering if anyone had any =
idea what's that
supposed to mean.

thanks
Greg

[Log4cpp-devel] log4cpp + cygwin + man pages

[Simon J. J. <sj...@er...>]

When log4cpp installs the man pages, it changes a '_' to a '::' on the man 
page file names. Unfortunately, this breaks the cygwin installation because 
these aren't valid windows names.

Is there a reason for the man pages to include '::' in the names? If not 
would it be possible to replace them with something else?

Cheers,

Simon

[Log4cpp-devel] Build on cygwin / Blanks in path

[Weber, Mathias-H. 1. S-PN-R. <Mat...@he...>]

I installed log4cpp on W2K using cygwin. As you expected in your =
installation notes it runs smoothly without major complaints. Good work!

But there is one little deficiency: I use a native Windows installation =
of doxygen which resides in "O:\Program Files\...". Unfortunately the =
installation struggles when it meets the blank in the path.=20

I have an allergy against configure/automake and friends so I did not =
trace down the problem to its very root. I just modified the Makefile to =
work with my specific path: There is a macro for doxygen for which I put =
the value into apostrophes. But the macro is never used so I had to =
modify another line as shown below.

Maybe it is worth for you to think about fixing this. I could live with =
the way it is right now.


Makefile:
------------8<----------------------------------------------
...
DOXYGEN =3D '/cygdrive/o/Program Files/doxygen/bin/doxygen'
#DOXYGEN =3D /cygdrive/o/Program Files/doxygen/bin/doxygen
...
html/api/index.html: Doxyfile
	${DOXYGEN}
#	'/cygdrive/o/Program Files/doxygen/bin/doxygen'
------------>8----------------------------------------------


Regards,
Mathias

[Log4cpp-devel] Want to contribute

[Jon S. <jst...@ho...>]

Hola!

I downloaded log4cpp a couple months ago and have been very impressed with
it; for hunting the bugs that get past unit tests, it's invaluable. Thank
you!

I have a feature request list, but unlike most feature requests, I'm willing
and eager to add them in myself. However, I wanted to submit my list, find
out development status, and get feedback on any design goals that you guys
might have. I don't want to step on any toes nor do I want to submit a patch
for something that someone else has solved, undoubtedly with more elegance.

So:

1. Multithreaded NDCs. I've been unable to get them working under MSVC7.
What needs to be done? Is log4cpp using boost::threads or is there a desire
to reduce dependencies on other projects (and therefore just use platform
specific thread code)? Either way (we use Boost), I'm happy to help.
Multithreaded NDCs would be priceless.

2. Priority stream manipulators. Sometimes I have events which could be
logged more conveniently if I could switch priorities (not horses) in
mid-stream. E.g.:

    myCat << Priority::notice << "Foo happened" << Priority::debug << " and
bar was " << bar; // this outputs the integral value of Priority::debug

Only if myCat's priority was at debug would we output the value of bar. This
seems very C++-like and would avoid such constructions:

    if(myCat.priority() == Priority::debug) {
        myCat << Priority::debug << "Foo happened and bar was " << bar; }
    else {
        myCat << Priority::notice << "Foo happened."; }

or

    myCat << Priority::notice << "Foo happened";
    myCat << Priority::debug << "Bar's value was " << bar;

3. Configurable field separators for BasicLayout. Using \t gets you Excel
nirvana.

4. Object Diagnostic Contexts. My team creates categories on a per-class
basis (with these categories roughly grouped into project categories). It
would be very useful if I could create per-instance diagnostic context
objects, tie them to the class category, and then use it to access the
category. Then when logging, the ODC could output its stack automatically to
the category.

For instance:

    class CFoo {
        private:
            log4cpp::ODC myLogger;
            int m_Val;

        public:
            CFoo() : myLogger(log4cpp::Category::getInstance("CFoo")),
m_Val(0)
            {
                std::stringstream dc;
                dc << "m_Val = " << m_Val;
                myLogger.push(dc.str());
                myLogger.debugStream() << "This is the first message.";
                myLogger.debugStream() << "This is the second message.";
            }
    }

with output of CFoo's constructor being as such:

    10001    CFoo    DEBUG    m_Val = 0    This is the first message.
    10002    CFoo    DEBUG    m_Val = 0    This is the second message.

I may explore some template wizardry to see if I couldn't use tie to output
whatever the current values of specified variables are, too. But that may be
a bit ambitious at first.

Any feedback/help is greatly appreciated. Otherwise I'll just start spamming
log4cpp with patches. :-)

Again, thanks much for the work that's gone into the project.



Jon Stewart
Lead Programmer
Horizon, A Glimpse of Tomorrow, Inc.