log4cplus-devel Mailing List for log4cplus (Page 11)
Logging Framework for C++
Brought to you by:
wilx
Menu
▾
▴
log4cplus-devel — Mailing list for log4cplus developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(3) |
Nov
(7) |
Dec
(15) |
| 2007 |
Jan
(19) |
Feb
(23) |
Mar
(40) |
Apr
(36) |
May
(18) |
Jun
(8) |
Jul
(10) |
Aug
(18) |
Sep
(18) |
Oct
(4) |
Nov
(1) |
Dec
(4) |
| 2008 |
Jan
(2) |
Feb
(1) |
Mar
(4) |
Apr
(16) |
May
(17) |
Jun
(15) |
Jul
(23) |
Aug
(7) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
(7) |
May
|
Jun
(5) |
Jul
(2) |
Aug
(9) |
Sep
|
Oct
(4) |
Nov
(6) |
Dec
(4) |
| 2010 |
Jan
(2) |
Feb
(2) |
Mar
(6) |
Apr
(5) |
May
(2) |
Jun
(13) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
(2) |
Jun
(11) |
Jul
(1) |
Aug
(4) |
Sep
(5) |
Oct
|
Nov
(4) |
Dec
|
| 2012 |
Jan
|
Feb
(13) |
Mar
(3) |
Apr
(5) |
May
(18) |
Jun
(22) |
Jul
(11) |
Aug
(25) |
Sep
(56) |
Oct
(1) |
Nov
(28) |
Dec
(3) |
| 2013 |
Jan
(66) |
Feb
(40) |
Mar
(61) |
Apr
(1) |
May
(45) |
Jun
(30) |
Jul
(30) |
Aug
(46) |
Sep
(23) |
Oct
(43) |
Nov
(95) |
Dec
(27) |
| 2014 |
Jan
(16) |
Feb
(19) |
Mar
(23) |
Apr
(18) |
May
(22) |
Jun
(12) |
Jul
(15) |
Aug
(16) |
Sep
(30) |
Oct
(10) |
Nov
(10) |
Dec
(5) |
| 2015 |
Jan
(2) |
Feb
(7) |
Mar
|
Apr
(1) |
May
(10) |
Jun
(3) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(6) |
Nov
(2) |
Dec
(15) |
| 2016 |
Jan
(21) |
Feb
(6) |
Mar
(30) |
Apr
(12) |
May
(11) |
Jun
(4) |
Jul
(2) |
Aug
(7) |
Sep
(13) |
Oct
|
Nov
(6) |
Dec
(8) |
| 2017 |
Jan
(21) |
Feb
(5) |
Mar
(7) |
Apr
(3) |
May
|
Jun
(4) |
Jul
(18) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Serg V. G. <s....@gm...> - 2012-11-16 15:48:14
|
Hello! It is possible to configure log4cplus to use GELF format to send messages to greylog server? Serg |
|
From: SourceForge.net <no...@so...> - 2012-11-13 22:02:05
|
Bugs item #3585440, was opened at 2012-11-08 10:28 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585440&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: v1.1.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Fix for std::codecvt in property.cxx Initial Comment: std::codecvt was given an incorrect set of template parameters ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-13 14:02 Message: I have fixed the compilation problem by using your solution for now. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-09 06:28 Message: I have just re-tested with VS 2010. It appears that some for of "null" codecvt that just copies the bytes into the wchar_ts is necessary. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-09 06:12 Message: I do not believe that the original unpatched line of code is entirely incorrect. The idea behind it is that when both type parameters are wchar_t, the compiler picks the default std::covdecvt<> template and does no conversion over the wchar_ts. Does this not work at all for you? Maybe it should instead be a custom "null" facet intherited from std::codecvt<wchar_t, char> just doing memcpy()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585440&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-13 22:01:33
|
Bugs item #3584858, was opened at 2012-11-06 13:24 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Issues with MinGW and v1.1.0 Initial Comment: I ran into some issues compiling the latest code with mingw. I've included a patch file to show the differences, though I am running it off a different SVN so it won't merge in correctly with the log4cplus trunk. Anyway, my issues: The define LOG4CPLUS_HAVE_INTRIN_H includes a header that isn't included in mingw (intrin.h). So I removed including that header as part of mingw. The function LockFile::open (int open_flags) calls _tsopen_s which is not part of mingw. I modified this function to switch on the UNICODE define and call _wsopen or _sopen. ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-13 14:01 Message: I have fixed some of the issues you have found. Please try building trunk, it should now compile ok. I have not yet fixed the sockets accept issue and the codecvt<> issue will need some more work as well. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-12 06:01 Message: For the snprintf.cxx change, I am applying one slightly different. TBH, I think this is a MinGW bug. === modified file 'src/snprintf.cxx' --- a/src/snprintf.cxx 2012-06-16 18:17:17 +0000 +++ b/src/snprintf.cxx 2012-11-12 13:58:45 +0000 @@ -127,8 +127,11 @@ #if defined (UNICODE) # if defined (LOG4CPLUS_HAVE__VSNWPRINTF_S) && defined (_TRUNCATE) ret = _vsnwprintf_s (dest, dest_size, _TRUNCATE, fmt, args); +# elif defined (LOG4CPLUS_HAVE_VSNWPRINTF) + ret = vsnwprintf (dest, dest_size, fmt, args); # else - ret = std::vswprintf (dest, dest_size, fmt, args); + using namespace std; + ret = vswprintf (dest, dest_size, fmt, args); # endif #else # if defined (LOG4CPLUS_HAVE_VSNPRINTF_S) && defined (_TRUNCATE) ---------------------------------------------------------------------- Comment By: Chris Steenwyk (csteenwyk) Date: 2012-11-07 08:13 Message: I was able to modify a few files to use the __MINGW64__ define and did some more research on the vsnwprintf. With the updates I attached I was able to get the build to work in: VS2010 MinGW GCC 4.6.3 on Ubuntu All with and without Unicode enabled. ---------------------------------------------------------------------- Comment By: Chris Steenwyk (csteenwyk) Date: 2012-11-07 06:00 Message: It looks like the 64-bit version defines both __MINGW64__ AND __MINGW32__ where the 32-bit version only defines __MINGW32__ So I think for the 64-bit specific stuff we could use __MINGW64__, and for all other mingw specific stuff we could use __MINGW32__ ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-06 13:51 Message: Thank you for the patch. You seem to be using MinGW32 distribution. Is this correct? The intrin.h header is present in MinGW64 distribution that I am using. Also the *_s() functions are present there. I wonder if there is not some preprocessor symbol that could help to distinguish these two compilers/distributions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-12 14:01:07
|
Bugs item #3584858, was opened at 2012-11-06 13:24 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Issues with MinGW and v1.1.0 Initial Comment: I ran into some issues compiling the latest code with mingw. I've included a patch file to show the differences, though I am running it off a different SVN so it won't merge in correctly with the log4cplus trunk. Anyway, my issues: The define LOG4CPLUS_HAVE_INTRIN_H includes a header that isn't included in mingw (intrin.h). So I removed including that header as part of mingw. The function LockFile::open (int open_flags) calls _tsopen_s which is not part of mingw. I modified this function to switch on the UNICODE define and call _wsopen or _sopen. ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-12 06:01 Message: For the snprintf.cxx change, I am applying one slightly different. TBH, I think this is a MinGW bug. === modified file 'src/snprintf.cxx' --- a/src/snprintf.cxx 2012-06-16 18:17:17 +0000 +++ b/src/snprintf.cxx 2012-11-12 13:58:45 +0000 @@ -127,8 +127,11 @@ #if defined (UNICODE) # if defined (LOG4CPLUS_HAVE__VSNWPRINTF_S) && defined (_TRUNCATE) ret = _vsnwprintf_s (dest, dest_size, _TRUNCATE, fmt, args); +# elif defined (LOG4CPLUS_HAVE_VSNWPRINTF) + ret = vsnwprintf (dest, dest_size, fmt, args); # else - ret = std::vswprintf (dest, dest_size, fmt, args); + using namespace std; + ret = vswprintf (dest, dest_size, fmt, args); # endif #else # if defined (LOG4CPLUS_HAVE_VSNPRINTF_S) && defined (_TRUNCATE) ---------------------------------------------------------------------- Comment By: Chris Steenwyk (csteenwyk) Date: 2012-11-07 08:13 Message: I was able to modify a few files to use the __MINGW64__ define and did some more research on the vsnwprintf. With the updates I attached I was able to get the build to work in: VS2010 MinGW GCC 4.6.3 on Ubuntu All with and without Unicode enabled. ---------------------------------------------------------------------- Comment By: Chris Steenwyk (csteenwyk) Date: 2012-11-07 06:00 Message: It looks like the 64-bit version defines both __MINGW64__ AND __MINGW32__ where the 32-bit version only defines __MINGW32__ So I think for the 64-bit specific stuff we could use __MINGW64__, and for all other mingw specific stuff we could use __MINGW32__ ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-06 13:51 Message: Thank you for the patch. You seem to be using MinGW32 distribution. Is this correct? The intrin.h header is present in MinGW64 distribution that I am using. Also the *_s() functions are present there. I wonder if there is not some preprocessor symbol that could help to distinguish these two compilers/distributions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-09 14:30:08
|
Bugs item #3585765, was opened at 2012-11-09 06:27 Message generated for change (Settings changed) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585765&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: v1.1.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) >Assigned to: Václav Zeman (wilx) Summary: ServerSocket::accept doesn't abort when the socket is closed Initial Comment: When working to create a logging server class, I created a thread that calls ServerSocket::accept. This function uses the winsock accept function which blocks. If this is blocking, the close command on the socket waits for it to return, so the thread would hang causing the app to not close in windows. I updated the socket-win32.cxx to use the select function in a loop to prevent this issue. See included diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585765&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-09 14:28:54
|
Bugs item #3585440, was opened at 2012-11-08 10:28 Message generated for change (Settings changed) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585440&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Other >Group: v1.1.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Fix for std::codecvt in property.cxx Initial Comment: std::codecvt was given an incorrect set of template parameters ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-09 06:28 Message: I have just re-tested with VS 2010. It appears that some for of "null" codecvt that just copies the bytes into the wchar_ts is necessary. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-09 06:12 Message: I do not believe that the original unpatched line of code is entirely incorrect. The idea behind it is that when both type parameters are wchar_t, the compiler picks the default std::covdecvt<> template and does no conversion over the wchar_ts. Does this not work at all for you? Maybe it should instead be a custom "null" facet intherited from std::codecvt<wchar_t, char> just doing memcpy()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585440&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-09 14:28:31
|
Bugs item #3585440, was opened at 2012-11-08 10:28 Message generated for change (Settings changed) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585440&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Fix for std::codecvt in property.cxx Initial Comment: std::codecvt was given an incorrect set of template parameters ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-09 06:28 Message: I have just re-tested with VS 2010. It appears that some for of "null" codecvt that just copies the bytes into the wchar_ts is necessary. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-09 06:12 Message: I do not believe that the original unpatched line of code is entirely incorrect. The idea behind it is that when both type parameters are wchar_t, the compiler picks the default std::covdecvt<> template and does no conversion over the wchar_ts. Does this not work at all for you? Maybe it should instead be a custom "null" facet intherited from std::codecvt<wchar_t, char> just doing memcpy()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585440&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-09 14:28:11
|
Patches item #3585440, was opened at 2012-11-08 10:28 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429075&aid=3585440&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v1.1.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Fix for std::codecvt in property.cxx Initial Comment: std::codecvt was given an incorrect set of template parameters ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-09 06:28 Message: I have just re-tested with VS 2010. It appears that some for of "null" codecvt that just copies the bytes into the wchar_ts is necessary. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-09 06:12 Message: I do not believe that the original unpatched line of code is entirely incorrect. The idea behind it is that when both type parameters are wchar_t, the compiler picks the default std::covdecvt<> template and does no conversion over the wchar_ts. Does this not work at all for you? Maybe it should instead be a custom "null" facet intherited from std::codecvt<wchar_t, char> just doing memcpy()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429075&aid=3585440&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-09 14:27:15
|
Bugs item #3585765, was opened at 2012-11-09 06:27 Message generated for change (Tracker Item Submitted) made by csteenwyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585765&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Nobody/Anonymous (nobody) Summary: ServerSocket::accept doesn't abort when the socket is closed Initial Comment: When working to create a logging server class, I created a thread that calls ServerSocket::accept. This function uses the winsock accept function which blocks. If this is blocking, the close command on the socket waits for it to return, so the thread would hang causing the app to not close in windows. I updated the socket-win32.cxx to use the select function in a loop to prevent this issue. See included diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585765&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-09 14:12:39
|
Patches item #3585440, was opened at 2012-11-08 10:28 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429075&aid=3585440&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: v1.1.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) >Assigned to: Václav Zeman (wilx) Summary: Fix for std::codecvt in property.cxx Initial Comment: std::codecvt was given an incorrect set of template parameters ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-09 06:12 Message: I do not believe that the original unpatched line of code is entirely incorrect. The idea behind it is that when both type parameters are wchar_t, the compiler picks the default std::covdecvt<> template and does no conversion over the wchar_ts. Does this not work at all for you? Maybe it should instead be a custom "null" facet intherited from std::codecvt<wchar_t, char> just doing memcpy()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429075&aid=3585440&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-09 13:50:49
|
Bugs item #3585446, was opened at 2012-11-08 11:12 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585446&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: v1.1.x >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Supress Warnings in Visual Studio Initial Comment: The do {} while( 0 ) macros in loggingmacros.h cause a plethora of warnings in Visual Studio. I suppressed this using the included diff. Could that be suppressed? ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-09 05:50 Message: Thank you. I have applied your patch with some small changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585446&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-09 13:25:09
|
Bugs item #3585446, was opened at 2012-11-08 11:12 Message generated for change (Settings changed) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585446&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Build >Group: v1.1.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) >Assigned to: Václav Zeman (wilx) Summary: Supress Warnings in Visual Studio Initial Comment: The do {} while( 0 ) macros in loggingmacros.h cause a plethora of warnings in Visual Studio. I suppressed this using the included diff. Could that be suppressed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585446&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-08 19:12:20
|
Bugs item #3585446, was opened at 2012-11-08 11:12 Message generated for change (Tracker Item Submitted) made by csteenwyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585446&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Nobody/Anonymous (nobody) Summary: Supress Warnings in Visual Studio Initial Comment: The do {} while( 0 ) macros in loggingmacros.h cause a plethora of warnings in Visual Studio. I suppressed this using the included diff. Could that be suppressed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3585446&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-08 18:28:13
|
Patches item #3585440, was opened at 2012-11-08 10:28 Message generated for change (Tracker Item Submitted) made by csteenwyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429075&aid=3585440&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for std::codecvt in property.cxx Initial Comment: std::codecvt was given an incorrect set of template parameters ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429075&aid=3585440&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-07 20:05:05
|
Support Requests item #3585233, was opened at 2012-11-07 12:05 Message generated for change (Tracker Item Submitted) made by csteenwyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3585233&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Nobody/Anonymous (nobody) Summary: Loggingmacros.h no longer included in logger.h Initial Comment: In a previous version of the library the include: #include <log4cplus/loggingmacros.h> was at the bottom of the main file logging.h. This allowed me to include logging.h and also get the ability to log using the macros LOG4CPLUS_DEBUG, LOG4CPLUS_INFO, etc. In version 1.1 this is no longer the case, requiring me to also provide the above include after my include for logger.h. Is this intentional? Is there a different main include I should use? It seems strange to me that I would always need to do: #include <log4cplus/logger.h> #include <log4cplus/loggingmacros.h> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3585233&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-07 20:01:05
|
Feature Requests item #3585231, was opened at 2012-11-07 12:01 Message generated for change (Tracker Item Submitted) made by csteenwyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429076&aid=3585231&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Appenders Group: None Status: Open Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Persist Logging Levels Initial Comment: I have an application in which I have added the ability to modify the log levels of the various logging instances as the program runs. It would be useful if there was a way to save this information so the next time I load the application the log levels are set to where I left them. I am able to get the configuration information for the various loggers, but not for the appenders. It would be useful if there were a function in each appender that would allow me to obtain the configuration of that appender: virtual void getProperties( log4cplus::helpers::Properties& props ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429076&aid=3585231&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-07 16:13:04
|
Bugs item #3584858, was opened at 2012-11-06 13:24 Message generated for change (Comment added) made by csteenwyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Issues with MinGW and v1.1.0 Initial Comment: I ran into some issues compiling the latest code with mingw. I've included a patch file to show the differences, though I am running it off a different SVN so it won't merge in correctly with the log4cplus trunk. Anyway, my issues: The define LOG4CPLUS_HAVE_INTRIN_H includes a header that isn't included in mingw (intrin.h). So I removed including that header as part of mingw. The function LockFile::open (int open_flags) calls _tsopen_s which is not part of mingw. I modified this function to switch on the UNICODE define and call _wsopen or _sopen. ---------------------------------------------------------------------- >Comment By: Chris Steenwyk (csteenwyk) Date: 2012-11-07 08:13 Message: I was able to modify a few files to use the __MINGW64__ define and did some more research on the vsnwprintf. With the updates I attached I was able to get the build to work in: VS2010 MinGW GCC 4.6.3 on Ubuntu All with and without Unicode enabled. ---------------------------------------------------------------------- Comment By: Chris Steenwyk (csteenwyk) Date: 2012-11-07 06:00 Message: It looks like the 64-bit version defines both __MINGW64__ AND __MINGW32__ where the 32-bit version only defines __MINGW32__ So I think for the 64-bit specific stuff we could use __MINGW64__, and for all other mingw specific stuff we could use __MINGW32__ ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-06 13:51 Message: Thank you for the patch. You seem to be using MinGW32 distribution. Is this correct? The intrin.h header is present in MinGW64 distribution that I am using. Also the *_s() functions are present there. I wonder if there is not some preprocessor symbol that could help to distinguish these two compilers/distributions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-07 14:00:23
|
Bugs item #3584858, was opened at 2012-11-06 13:24 Message generated for change (Comment added) made by csteenwyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Issues with MinGW and v1.1.0 Initial Comment: I ran into some issues compiling the latest code with mingw. I've included a patch file to show the differences, though I am running it off a different SVN so it won't merge in correctly with the log4cplus trunk. Anyway, my issues: The define LOG4CPLUS_HAVE_INTRIN_H includes a header that isn't included in mingw (intrin.h). So I removed including that header as part of mingw. The function LockFile::open (int open_flags) calls _tsopen_s which is not part of mingw. I modified this function to switch on the UNICODE define and call _wsopen or _sopen. ---------------------------------------------------------------------- >Comment By: Chris Steenwyk (csteenwyk) Date: 2012-11-07 06:00 Message: It looks like the 64-bit version defines both __MINGW64__ AND __MINGW32__ where the 32-bit version only defines __MINGW32__ So I think for the 64-bit specific stuff we could use __MINGW64__, and for all other mingw specific stuff we could use __MINGW32__ ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-06 13:51 Message: Thank you for the patch. You seem to be using MinGW32 distribution. Is this correct? The intrin.h header is present in MinGW64 distribution that I am using. Also the *_s() functions are present there. I wonder if there is not some preprocessor symbol that could help to distinguish these two compilers/distributions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 21:51:05
|
Bugs item #3584858, was opened at 2012-11-06 13:24 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Issues with MinGW and v1.1.0 Initial Comment: I ran into some issues compiling the latest code with mingw. I've included a patch file to show the differences, though I am running it off a different SVN so it won't merge in correctly with the log4cplus trunk. Anyway, my issues: The define LOG4CPLUS_HAVE_INTRIN_H includes a header that isn't included in mingw (intrin.h). So I removed including that header as part of mingw. The function LockFile::open (int open_flags) calls _tsopen_s which is not part of mingw. I modified this function to switch on the UNICODE define and call _wsopen or _sopen. ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-06 13:51 Message: Thank you for the patch. You seem to be using MinGW32 distribution. Is this correct? The intrin.h header is present in MinGW64 distribution that I am using. Also the *_s() functions are present there. I wonder if there is not some preprocessor symbol that could help to distinguish these two compilers/distributions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 21:24:12
|
Bugs item #3584858, was opened at 2012-11-06 13:24 Message generated for change (Tracker Item Submitted) made by csteenwyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Steenwyk (csteenwyk) Assigned to: Václav Zeman (wilx) Summary: Issues with MinGW and v1.1.0 Initial Comment: I ran into some issues compiling the latest code with mingw. I've included a patch file to show the differences, though I am running it off a different SVN so it won't merge in correctly with the log4cplus trunk. Anyway, my issues: The define LOG4CPLUS_HAVE_INTRIN_H includes a header that isn't included in mingw (intrin.h). So I removed including that header as part of mingw. The function LockFile::open (int open_flags) calls _tsopen_s which is not part of mingw. I modified this function to switch on the UNICODE define and call _wsopen or _sopen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3584858&group_id=40830 |
|
From: Václav Z. <vha...@gm...> - 2012-10-02 19:12:20
|
Hi.
I have released log4cplus 1.1.0. Relative to the 1.1.0-RC10, it contains
only minor changes.
Here is a full change log of all releases in the 1.1.0 series:
log4cplus 1.1.0
- Fixed MacOS X support - Reimplemented semaphores using named ones
for Apple builds.
- Fixed resource leak on failure in openSocket().
- Improved configuration file modification check to include file size,
in addition to file modification time.
log4cplus 1.1.0-RC10
- Fixed non-STLPort4 builds with Solaris Studio. Switch
'-library=stlport4' is only added if CXXFLAGS does not already
contain a switch matching -library=(stlport4|stdcxx4|Cstd).
- Fixed --disable-shared MinGW builds.
- Fixed non-working MinGW DLL binaries. DllMain() was not being called
because of missing extern "C" in its definition.
- CMake build configuration checks have been improved. (Chernyshev
Vyacheslav)
- GCC switch -O2 is only added if CXXFLAGS does not already contain
any other -O.
- Improved logging speed using SysLogAppender and Log4jUdpAppender by
optimizations in both the loggers and in common sockets code.
- FileAppender locale can now be specified in properties files using
Locale property. See FileAppender Doxygen documentation for more
details.
log4cplus 1.1.0-RC9
- Improved Log4jUdpAppender compatibility with Chainsaw.
- Fixed crash, bugs #3467112 and #3563699, related to thread-local
storage destruction.
- Fixed build with Visual Studio 2005, bug #3565529. (xg00)
- Created Cygwin port's .cygport definition for log4cplus.
- Improved hiding of private symbols using GCC's
__attribute__((visibility("hidden"))) and Solaris Studio's __hidden.
- Fixed build in environments where DEBUG (and other log level names)
are macros. (Chernyshev Vyacheslav)
- Improved configuration of threads support. (Jens Rehsack)
log4cplus 1.1.0-RC8
- Turned on __thread (TLS) detection on NetBSD 5.1.0 and later that
has been previously disabled.
- Improved compatibility with log4cplus 1.0.x: allow using log4cplus
1.0.x log level to string callbacks in 1.1.x.
- Improved various M4 macros.
- Added detection and use C++11 thread_local.
- Fixed XML entities escaping in Log4jUdpAppender.
- Re-added synchronization between ConsoleAppender and LogLog.
- Changed C logger API to return int instead of bool.
- Added C logger API to Visual Studio 2010 projects.
- Implemented remote syslog logging using UDP in SysLogAppender.
- Enabled SysLogAppender on Windows with only remote syslog logging
enabled.
log4cplus 1.1.0-RC7
IMPORTANT: Builds with --with-iconv configure switch now assume UTF-8
for plain char strings.
- Bumped up SO version for UDP sockets support related changes.
- Removed Windows CE support.
- Regenerated with Automake 1.12.2.
- Fixed Fedora RPM builds spec file.
- Implemented log4cplus.disableOverride similar to log4j's
log4j.disableOverride.
- Improved support of profiling and debugging builds with Sun CC.
- Added documentation for configure script options.
- Added detection and use of clock_nanosleep().
- Disabled __thread (TLS) detection for NetBSD. It is broken there.
- New appender: Log4jUdpAppender. It allows logging using UDP with
log4j XML payload to Chainsaw or Log2Console. (Siva Chandran P)
- Added support for __func__ as function name source for logging
events.
log4cplus 1.1.0-RC6
- Fixed compilation for build with wchar_t being alias to unsigned
short (/Zc:wchar_t-) (Windows).
- Added new appender CLFSAppender (experimental), based on Microsoft
Common Log File System API.
- Added new appender Qt4DebugAppender (experimenta), based on Qt4's
qDebug(), qWarning() and qCritical() functions.
- Fixed bug #3530769 - compilation issues with Visual Studio 2011.
- Added log4cplus.quietMode property handling to PropertyConfigurator.
- Added #pragma once to all headers.
- Implemented Time::gettimeofday() using Win32 API's
GetSystemTimeAsFileTime().
- Moved file based locking from FileAppender to Appender to make it
available for all appenders.
- Changed Windows configuration to use __declspec(thread) when
compiling for Windows Vista or later and TlsAlloc() otherwise.
- Implemented %r PatternLayout format specifier - miliseconds since
process start.
- Fixed bug #3101459 - TTCCLayout time is not in milliseconds since
process start by default.
log4cplus 1.1.0-RC5
- Fixed single threaded log4cplus build issues.
- Added ability to log to std::cerr (Andreas Bießmann).
- Fixed disabling of LOG4CPLUS_*_FMT() macros.
log4cplus 1.1.0-RC4
IMPORTANT: Compilation with Solaris Studio now depends on STLPort
(-library=stlport4 switch). The default Cstd library is not
conforming enough for use in log4cplus.
- Improved behaviour of log4cplus as a component of larger CMake based
project (Andreas Bießmann).
- Updated various Autoconf detection scripts in m4/ directory to newer
versions.
- Fixed some signedness and overflow warnings.
- Improved Autotools build system's behaviour for cross compilation.
- Added detection of C++11 <atomic> header and related
functions. Implemented SharedObject reference counting using C++11
atomics where possible.
- Fixed compilation with GCC 4.6 in C++11 mode.
- Fixed some single-threaded compilation and run time issues.
- Fixed bug #3520891 - FileAppender buffering issue.
- Updated to Autoconf 2.69, Automake 1.12 and Libtool 2.4.2.
- Documented build procedure for Solaris Studio.
- Improved support for Solaris Studio in configure.in.
log4cplus 1.1.0-RC3
- Fixed log4cplusS.vcxproj - Added missing source files to the
project.
log4cplus 1.1.0-RC2
- CMake build system fixes.
- Fixed TTCCLayout double time stamp issue.
log4cplus 1.1.0-RC1
Important changes relative to PRODUCTION_1_0_x branch:
- Added AsyncAppender.
- Added simple C interface for interoperability with C.
- Added inter-process file locking to file appenders to allow logging
into a single log file from multiple processes.
- Added Mapped Diagnostic Context (MDC) and associated converter (%X).
- Added alternative thread identification (%T) converter to pattern layout.
- Added function name converter (%M).
- Added wchar_t <-> char conversion implementations based on standard
C locale functions and based on iconv().
- Added DeviceAppender to allow use of Boost.IOStream's Sink as appender.
- Added LOG4CPLUS_*_FMT() macros to allow printf-like formatted output
where it is possible.
- Logging macros now accept both logger name as string and Logger
instance as their first parameter.
--
VZ
|
|
From: SourceForge.net <no...@so...> - 2012-09-26 03:03:37
|
Support Requests item #3570926, was opened at 2012-09-22 21:00 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3570926&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v1.1.0 >Status: Closed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Václav Zeman (wilx) Summary: Buffer overrun with Hello World example Initial Comment: I'm attempting to use logforcplus in my first c++ project in over ten years, so please assume I might have done something simple wrong. I cannot get the Hello World example working without buffer overrun errors. I downloaded log4cplus-1.1.0-rc10. I used VS2010 to open the sln in msvc10 folder, set log4cplus project to Debug_Unicode, and compile. I created a new project directory log4cplusDemo, with subdirectories bin, include, lib, and src. "Bin" contains log4cplusUD.dll and pdb, "include" contains include\log4cplus, and "lib" contains log4cplusUD.lib. I used VS2012 to create a new C++ Win32 exe in the "src" directory. Project Properties..Configuration Properties..General..Character Set is Unicode. Configuration Properties..C/C++..General..Additional Include Directories has a reference to "include". Configuration Properties..Linker..General..Additional Library Directories has a reference to "lib". Linker..Input..Additional Dependencies has a reference to "log4cplusUD.lib". Trying the hello world example resulted in a buffer overrun error. I was able to expand the macro and isolate the failing line. Replacing it with a hardcoded string works, but causes a buffer overrun when main() exits. What am I doing wrong? #include "stdafx.h" #include <log4cplus/logger.h> #include <log4cplus/loggingmacros.h> #include <log4cplus/configurator.h> using namespace log4cplus; int _tmain(int argc, _TCHAR* argv[]) { BasicConfigurator config; config.configure(); Logger logger = Logger::getInstance(LOG4CPLUS_TEXT("main")); // This causes buffer overrun on this line // LOG4CPLUS_WARN(logger, LOG4CPLUS_TEXT("Hello, World!")); // This works (by commenting out original call to .str() and sending a string directly), // but buffer overflow error occurs on return statement. do { log4cplus::Logger const & _l = log4cplus::detail::macros_get_logger (logger); // I can't figure out this macro, and it's just checking if the desired log level is enabled so comment out // if (LOG4CPLUS_MACRO_LOGLEVEL_PRED ( //_l.isEnabledFor (log4cplus::logLevel), logLevel)) { log4cplus::tostringstream & _log4cplus_buf = log4cplus::detail::get_macro_body_oss (); _log4cplus_buf << LOG4CPLUS_TEXT("Hello, World!"); log4cplus::detail::macro_forced_log (_l, log4cplus::WARN_LOG_LEVEL, // This causes buffer overflow error, replace with string directly //_log4cplus_buf.str(), L"Hello world!", __FILE__, __LINE__, LOG4CPLUS_MACRO_FUNCTION () ); //} } while (0); getchar(); return 0; } ---------------------------------------------------------------------- >Comment By: https://www.google.com/accounts () Date: 2012-09-25 20:03 Message: I deleted all previous source and binaries and started from scratch and it worked. *facepalm* Binary incompatibility between compiler versions is foreign to me, but now I know why so many c++ projects have detailed build instructions and rarely prebuilt binaries. Thanks so much for the hand holding! ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-09-24 06:43 Message: I have tried to reproduce your problem with Visual Studio 2012 using trunk source (because there were not any changes that could possibly influence the outcome of the minimal BasicConfigurator test). I cannot reproduce it. I have tried a performance_test and thread_test in their original form. Then I have removed the source in main.cxx of thread_test and pasted in yours. It still works fine. My guess is that you are still mixing stuff built with VS 2010 and VS 2012. Please double check that the log4cplusUD.{dll,lib} etc. files are really built by the same Visual Studio as your test/application. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-09-23 22:42 Message: The code should work in both VS 2010 and VS 2012 but mixing binaries from different VS versions is not possible. I will try to take a look at the problem but first I will have to get VS 2012. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2012-09-23 20:10 Message: Building log4cplus in VS 2012 didn't help (yes, it does open the VS2010 solution just fine). I moved hello world to VS 2010 and it works, even with the VS 2012 compiled log4cplus, which I thought was interesting. After digging through the project options for VS 2012 hello world, I found Configuration Properties..General..Platform Toolkit. It was set to VS 2012 (v110), setting it to VS 2010 (v100) made the buffer overrun disappear, and I was able run hello world without any macro hacking. Unfortunately this means choosing between using the new C++11 libraries or log4cplus in my project. I flipped it back to v110 and experimented some. The buffer overrun at the end of main() in the code I first posted is actually coming from the declaration of BasicConfigurator. Using the v110 toolset, simply doing this: int _tmain(int argc, _TCHAR* argv[]) { BasicConfigurator config; return 0; } causes the overrun at the return statement. I thought you might want to know for when you start adding C++11 support. Thanks for your time and advice on this, I really appreciate it. Your project looked great and I'm disappointed I'm not going to be able to use it. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-09-22 22:48 Message: AFAIK, you cannot do that. Trying to combine VS 2010 built library and VS 2012 compiled executable, in general, does not work. Build log4cplus using VS 2012 as well. I have not tried but there should be no problem opening the VS 2010 solution in VS 2012 and building it there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3570926&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-09-24 13:43:16
|
Support Requests item #3570926, was opened at 2012-09-22 21:00 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3570926&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v1.1.0 Status: Pending Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Václav Zeman (wilx) Summary: Buffer overrun with Hello World example Initial Comment: I'm attempting to use logforcplus in my first c++ project in over ten years, so please assume I might have done something simple wrong. I cannot get the Hello World example working without buffer overrun errors. I downloaded log4cplus-1.1.0-rc10. I used VS2010 to open the sln in msvc10 folder, set log4cplus project to Debug_Unicode, and compile. I created a new project directory log4cplusDemo, with subdirectories bin, include, lib, and src. "Bin" contains log4cplusUD.dll and pdb, "include" contains include\log4cplus, and "lib" contains log4cplusUD.lib. I used VS2012 to create a new C++ Win32 exe in the "src" directory. Project Properties..Configuration Properties..General..Character Set is Unicode. Configuration Properties..C/C++..General..Additional Include Directories has a reference to "include". Configuration Properties..Linker..General..Additional Library Directories has a reference to "lib". Linker..Input..Additional Dependencies has a reference to "log4cplusUD.lib". Trying the hello world example resulted in a buffer overrun error. I was able to expand the macro and isolate the failing line. Replacing it with a hardcoded string works, but causes a buffer overrun when main() exits. What am I doing wrong? #include "stdafx.h" #include <log4cplus/logger.h> #include <log4cplus/loggingmacros.h> #include <log4cplus/configurator.h> using namespace log4cplus; int _tmain(int argc, _TCHAR* argv[]) { BasicConfigurator config; config.configure(); Logger logger = Logger::getInstance(LOG4CPLUS_TEXT("main")); // This causes buffer overrun on this line // LOG4CPLUS_WARN(logger, LOG4CPLUS_TEXT("Hello, World!")); // This works (by commenting out original call to .str() and sending a string directly), // but buffer overflow error occurs on return statement. do { log4cplus::Logger const & _l = log4cplus::detail::macros_get_logger (logger); // I can't figure out this macro, and it's just checking if the desired log level is enabled so comment out // if (LOG4CPLUS_MACRO_LOGLEVEL_PRED ( //_l.isEnabledFor (log4cplus::logLevel), logLevel)) { log4cplus::tostringstream & _log4cplus_buf = log4cplus::detail::get_macro_body_oss (); _log4cplus_buf << LOG4CPLUS_TEXT("Hello, World!"); log4cplus::detail::macro_forced_log (_l, log4cplus::WARN_LOG_LEVEL, // This causes buffer overflow error, replace with string directly //_log4cplus_buf.str(), L"Hello world!", __FILE__, __LINE__, LOG4CPLUS_MACRO_FUNCTION () ); //} } while (0); getchar(); return 0; } ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-09-24 06:43 Message: I have tried to reproduce your problem with Visual Studio 2012 using trunk source (because there were not any changes that could possibly influence the outcome of the minimal BasicConfigurator test). I cannot reproduce it. I have tried a performance_test and thread_test in their original form. Then I have removed the source in main.cxx of thread_test and pasted in yours. It still works fine. My guess is that you are still mixing stuff built with VS 2010 and VS 2012. Please double check that the log4cplusUD.{dll,lib} etc. files are really built by the same Visual Studio as your test/application. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-09-23 22:42 Message: The code should work in both VS 2010 and VS 2012 but mixing binaries from different VS versions is not possible. I will try to take a look at the problem but first I will have to get VS 2012. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2012-09-23 20:10 Message: Building log4cplus in VS 2012 didn't help (yes, it does open the VS2010 solution just fine). I moved hello world to VS 2010 and it works, even with the VS 2012 compiled log4cplus, which I thought was interesting. After digging through the project options for VS 2012 hello world, I found Configuration Properties..General..Platform Toolkit. It was set to VS 2012 (v110), setting it to VS 2010 (v100) made the buffer overrun disappear, and I was able run hello world without any macro hacking. Unfortunately this means choosing between using the new C++11 libraries or log4cplus in my project. I flipped it back to v110 and experimented some. The buffer overrun at the end of main() in the code I first posted is actually coming from the declaration of BasicConfigurator. Using the v110 toolset, simply doing this: int _tmain(int argc, _TCHAR* argv[]) { BasicConfigurator config; return 0; } causes the overrun at the return statement. I thought you might want to know for when you start adding C++11 support. Thanks for your time and advice on this, I really appreciate it. Your project looked great and I'm disappointed I'm not going to be able to use it. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-09-22 22:48 Message: AFAIK, you cannot do that. Trying to combine VS 2010 built library and VS 2012 compiled executable, in general, does not work. Build log4cplus using VS 2012 as well. I have not tried but there should be no problem opening the VS 2010 solution in VS 2012 and building it there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3570926&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-09-24 05:42:21
|
Support Requests item #3570926, was opened at 2012-09-22 21:00 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3570926&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v1.1.0 Status: Pending Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Václav Zeman (wilx) Summary: Buffer overrun with Hello World example Initial Comment: I'm attempting to use logforcplus in my first c++ project in over ten years, so please assume I might have done something simple wrong. I cannot get the Hello World example working without buffer overrun errors. I downloaded log4cplus-1.1.0-rc10. I used VS2010 to open the sln in msvc10 folder, set log4cplus project to Debug_Unicode, and compile. I created a new project directory log4cplusDemo, with subdirectories bin, include, lib, and src. "Bin" contains log4cplusUD.dll and pdb, "include" contains include\log4cplus, and "lib" contains log4cplusUD.lib. I used VS2012 to create a new C++ Win32 exe in the "src" directory. Project Properties..Configuration Properties..General..Character Set is Unicode. Configuration Properties..C/C++..General..Additional Include Directories has a reference to "include". Configuration Properties..Linker..General..Additional Library Directories has a reference to "lib". Linker..Input..Additional Dependencies has a reference to "log4cplusUD.lib". Trying the hello world example resulted in a buffer overrun error. I was able to expand the macro and isolate the failing line. Replacing it with a hardcoded string works, but causes a buffer overrun when main() exits. What am I doing wrong? #include "stdafx.h" #include <log4cplus/logger.h> #include <log4cplus/loggingmacros.h> #include <log4cplus/configurator.h> using namespace log4cplus; int _tmain(int argc, _TCHAR* argv[]) { BasicConfigurator config; config.configure(); Logger logger = Logger::getInstance(LOG4CPLUS_TEXT("main")); // This causes buffer overrun on this line // LOG4CPLUS_WARN(logger, LOG4CPLUS_TEXT("Hello, World!")); // This works (by commenting out original call to .str() and sending a string directly), // but buffer overflow error occurs on return statement. do { log4cplus::Logger const & _l = log4cplus::detail::macros_get_logger (logger); // I can't figure out this macro, and it's just checking if the desired log level is enabled so comment out // if (LOG4CPLUS_MACRO_LOGLEVEL_PRED ( //_l.isEnabledFor (log4cplus::logLevel), logLevel)) { log4cplus::tostringstream & _log4cplus_buf = log4cplus::detail::get_macro_body_oss (); _log4cplus_buf << LOG4CPLUS_TEXT("Hello, World!"); log4cplus::detail::macro_forced_log (_l, log4cplus::WARN_LOG_LEVEL, // This causes buffer overflow error, replace with string directly //_log4cplus_buf.str(), L"Hello world!", __FILE__, __LINE__, LOG4CPLUS_MACRO_FUNCTION () ); //} } while (0); getchar(); return 0; } ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-09-23 22:42 Message: The code should work in both VS 2010 and VS 2012 but mixing binaries from different VS versions is not possible. I will try to take a look at the problem but first I will have to get VS 2012. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2012-09-23 20:10 Message: Building log4cplus in VS 2012 didn't help (yes, it does open the VS2010 solution just fine). I moved hello world to VS 2010 and it works, even with the VS 2012 compiled log4cplus, which I thought was interesting. After digging through the project options for VS 2012 hello world, I found Configuration Properties..General..Platform Toolkit. It was set to VS 2012 (v110), setting it to VS 2010 (v100) made the buffer overrun disappear, and I was able run hello world without any macro hacking. Unfortunately this means choosing between using the new C++11 libraries or log4cplus in my project. I flipped it back to v110 and experimented some. The buffer overrun at the end of main() in the code I first posted is actually coming from the declaration of BasicConfigurator. Using the v110 toolset, simply doing this: int _tmain(int argc, _TCHAR* argv[]) { BasicConfigurator config; return 0; } causes the overrun at the return statement. I thought you might want to know for when you start adding C++11 support. Thanks for your time and advice on this, I really appreciate it. Your project looked great and I'm disappointed I'm not going to be able to use it. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-09-22 22:48 Message: AFAIK, you cannot do that. Trying to combine VS 2010 built library and VS 2012 compiled executable, in general, does not work. Build log4cplus using VS 2012 as well. I have not tried but there should be no problem opening the VS 2010 solution in VS 2012 and building it there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3570926&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-09-24 03:10:27
|
Support Requests item #3570926, was opened at 2012-09-22 21:00 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3570926&group_id=40830 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v1.1.0 Status: Pending Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Václav Zeman (wilx) Summary: Buffer overrun with Hello World example Initial Comment: I'm attempting to use logforcplus in my first c++ project in over ten years, so please assume I might have done something simple wrong. I cannot get the Hello World example working without buffer overrun errors. I downloaded log4cplus-1.1.0-rc10. I used VS2010 to open the sln in msvc10 folder, set log4cplus project to Debug_Unicode, and compile. I created a new project directory log4cplusDemo, with subdirectories bin, include, lib, and src. "Bin" contains log4cplusUD.dll and pdb, "include" contains include\log4cplus, and "lib" contains log4cplusUD.lib. I used VS2012 to create a new C++ Win32 exe in the "src" directory. Project Properties..Configuration Properties..General..Character Set is Unicode. Configuration Properties..C/C++..General..Additional Include Directories has a reference to "include". Configuration Properties..Linker..General..Additional Library Directories has a reference to "lib". Linker..Input..Additional Dependencies has a reference to "log4cplusUD.lib". Trying the hello world example resulted in a buffer overrun error. I was able to expand the macro and isolate the failing line. Replacing it with a hardcoded string works, but causes a buffer overrun when main() exits. What am I doing wrong? #include "stdafx.h" #include <log4cplus/logger.h> #include <log4cplus/loggingmacros.h> #include <log4cplus/configurator.h> using namespace log4cplus; int _tmain(int argc, _TCHAR* argv[]) { BasicConfigurator config; config.configure(); Logger logger = Logger::getInstance(LOG4CPLUS_TEXT("main")); // This causes buffer overrun on this line // LOG4CPLUS_WARN(logger, LOG4CPLUS_TEXT("Hello, World!")); // This works (by commenting out original call to .str() and sending a string directly), // but buffer overflow error occurs on return statement. do { log4cplus::Logger const & _l = log4cplus::detail::macros_get_logger (logger); // I can't figure out this macro, and it's just checking if the desired log level is enabled so comment out // if (LOG4CPLUS_MACRO_LOGLEVEL_PRED ( //_l.isEnabledFor (log4cplus::logLevel), logLevel)) { log4cplus::tostringstream & _log4cplus_buf = log4cplus::detail::get_macro_body_oss (); _log4cplus_buf << LOG4CPLUS_TEXT("Hello, World!"); log4cplus::detail::macro_forced_log (_l, log4cplus::WARN_LOG_LEVEL, // This causes buffer overflow error, replace with string directly //_log4cplus_buf.str(), L"Hello world!", __FILE__, __LINE__, LOG4CPLUS_MACRO_FUNCTION () ); //} } while (0); getchar(); return 0; } ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2012-09-23 20:10 Message: Building log4cplus in VS 2012 didn't help (yes, it does open the VS2010 solution just fine). I moved hello world to VS 2010 and it works, even with the VS 2012 compiled log4cplus, which I thought was interesting. After digging through the project options for VS 2012 hello world, I found Configuration Properties..General..Platform Toolkit. It was set to VS 2012 (v110), setting it to VS 2010 (v100) made the buffer overrun disappear, and I was able run hello world without any macro hacking. Unfortunately this means choosing between using the new C++11 libraries or log4cplus in my project. I flipped it back to v110 and experimented some. The buffer overrun at the end of main() in the code I first posted is actually coming from the declaration of BasicConfigurator. Using the v110 toolset, simply doing this: int _tmain(int argc, _TCHAR* argv[]) { BasicConfigurator config; return 0; } causes the overrun at the return statement. I thought you might want to know for when you start adding C++11 support. Thanks for your time and advice on this, I really appreciate it. Your project looked great and I'm disappointed I'm not going to be able to use it. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-09-22 22:48 Message: AFAIK, you cannot do that. Trying to combine VS 2010 built library and VS 2012 compiled executable, in general, does not work. Build log4cplus using VS 2012 as well. I have not tried but there should be no problem opening the VS 2010 solution in VS 2012 and building it there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3570926&group_id=40830 |
927 messages has been excluded from this view by a project administrator.
