log4cplus-devel Mailing List for log4cplus (Page 10)
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: Marcel L. <mar...@zo...> - 2013-05-23 17:47:42
|
Op 23-05-13 15:25, Brice Copy schreef: > > Hello, > > I am compiling log4cplus from source on Red Hat enterprise 5 (CERN > scientific linux) 32 and 64 bits. > > The point is to package Log4cplus in my Java webstart project (to > enable logging in a native C++ library). > > The problem is that when I use the configure and make scripts, it > produces a liblog4cplus-1.1.so.5 library file. > > I really need the library file that ends with ".so" - or Java > webstart will not unpack it from the native library JAR package and > add it to the library path. > > Renaming the file to liblog4cplus-1.1.so does not work, because I link > my own native library to log4cplus, and the liblog4cplus-1.1.so.5 file > contains the SONAME set to "liblog4cplus-1.1.so.5" (so the linker will > link to liblog4cplus-1.1.so but my own library expects > liblog4cplus-1.1.so.5 to be present on the path). > > Is there a "configure" option I can use to force the SONAME to > liblog4cplus-1.1.so ? > > Or can I strip the SONAME from the final library, thereby forcing the > linker to link to the library file name liblog4cplus-1.1.so ? > > Thanks, > > Brice > > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > > > _______________________________________________ > Log4cplus-devel mailing list > Log...@li... > https://lists.sourceforge.net/lists/listinfo/log4cplus-devel Hi Brice, I may be wrong, but isn't the Linux way of handling this to create a symbolic link. Usually, the SONAME contains the full library name (or at least the part containing the major version number). Cheers, Marcel Loose. |
|
From: Brice C. <Bri...@ce...> - 2013-05-23 13:25:29
|
Hello, I am compiling log4cplus from source on Red Hat enterprise 5 (CERN scientific linux) 32 and 64 bits. The point is to package Log4cplus in my Java webstart project (to enable logging in a native C++ library). The problem is that when I use the configure and make scripts, it produces a liblog4cplus-1.1.so.5 library file. I really need the library file that ends with ".so" - or Java webstart will not unpack it from the native library JAR package and add it to the library path. Renaming the file to liblog4cplus-1.1.so does not work, because I link my own native library to log4cplus, and the liblog4cplus-1.1.so.5 file contains the SONAME set to "liblog4cplus-1.1.so.5" (so the linker will link to liblog4cplus-1.1.so but my own library expects liblog4cplus-1.1.so.5 to be present on the path). Is there a "configure" option I can use to force the SONAME to liblog4cplus-1.1.so ? Or can I strip the SONAME from the final library, thereby forcing the linker to link to the library file name liblog4cplus-1.1.so ? Thanks, Brice |
|
From: Václav Z. <vha...@gm...> - 2013-05-15 07:46:30
|
On 14 May 2013 14:48, Alexander Dahl wrote: > Hei hei, > > I started playing around with log4cplus and wondered why I don't get > thread names displayed. Before digging to deep in my own code I had a > look at the test programs in the log4cplus source, namely thread_test. I > compiled log4cplus 1.1.1 on an up to date Debian Wheezy without any > special options when calling ./configure and get this (and more): > > % ./thread_test > main Priority: NOTSET > 0 [3049802608] WARN test.TestThread <> - Thread-3 TestThread.run()- > Starting... > 0 [3049802608] TRACE SlowObject <Thread-3 loop> - ENTER: > SlowObject::doSomething() > 1 [3049802608] INFO SlowObject <Thread-3 loop> - Actually doing > something... > 1 [3058195312] WARN test.TestThread <> - Thread-2 TestThread.run()- > Starting... > 1 [3058195312] TRACE SlowObject <Thread-2 loop> - ENTER: > SlowObject::doSomething() > 1 [3066588016] WARN test.TestThread <> - Thread-1 TestThread.run()- > Starting... > 1 [3066588016] TRACE SlowObject <Thread-1 loop> - ENTER: > SlowObject::doSomething() > 1 [3074980720] WARN test.TestThread <> - Thread-0 TestThread.run()- > Starting... > 2 [3074980720] TRACE SlowObject <Thread-0 loop> - ENTER: > SlowObject::doSomething() > 3 [3049802608] INFO SlowObject <Thread-3 loop> - Actually doing > something...1, 2, 3, testing...DONE > 3 [3058195312] INFO SlowObject <Thread-2 loop> - Actually doing > something... > 3 [3049802608] TRACE SlowObject <Thread-3 loop> - EXIT: > SlowObject::doSomething() > 3 [3049802608] TRACE SlowObject <Thread-3 loop> - ENTER: > SlowObject::doSomething() > 3 [3058195312] INFO SlowObject <Thread-2 loop> - Actually doing > something...1, 2, 3, testing...DONE > 3 [3066588016] INFO SlowObject <Thread-1 loop> - Actually doing > something... > > The part in the <> seems to contain the thread name set in > tests/thread_test/main.cxx line 100. Looking at layout.cxx a line in > this layout starts with timestamp, has some thread info in square > brackets, log level, logger name, NDC in <> and finally the message > itself. The thread info in square brackets is the pthread_t value returned by pthread_self(). > > This looks a little different than the example output on > http://log4cplus.sourceforge.net/docs/html/classlog4cplus_1_1TTCCLayout.html > which seems to have no number in square brackets but some name and no > <> at all. What's the number in the square brackets? The log snippet in the documentation is wrong. I shall fix it. The snippet comes from log4j. This is because log4cplus is derived from log4j and some of log4cplus' documentation was copy/pasted from log4j without alteration. > > This question aims how I can set some kind of thread name without using > the log4cplus thread class which is displayed with TTCC layout (or maybe > PatternLayout), but maybe I should understand the example first. At present (log4cplus 1.1.1 or earlier), the best you can get is either pthread_self() value or SYS_gettid value on Linux. I know that there are various extensions to pthreads API that allow to set and get thread names. None of them are accessible from stock log4cplus at the moment. If you need named threads, I suggest that you use the NDC or MDC facilities for that. You will have to set the thread name into NDC or MDC manually. -- VZ |
|
From: Alexander D. <po...@le...> - 2013-05-14 12:48:55
|
Hei hei, I started playing around with log4cplus and wondered why I don't get thread names displayed. Before digging to deep in my own code I had a look at the test programs in the log4cplus source, namely thread_test. I compiled log4cplus 1.1.1 on an up to date Debian Wheezy without any special options when calling ./configure and get this (and more): % ./thread_test main Priority: NOTSET 0 [3049802608] WARN test.TestThread <> - Thread-3 TestThread.run()- Starting... 0 [3049802608] TRACE SlowObject <Thread-3 loop> - ENTER: SlowObject::doSomething() 1 [3049802608] INFO SlowObject <Thread-3 loop> - Actually doing something... 1 [3058195312] WARN test.TestThread <> - Thread-2 TestThread.run()- Starting... 1 [3058195312] TRACE SlowObject <Thread-2 loop> - ENTER: SlowObject::doSomething() 1 [3066588016] WARN test.TestThread <> - Thread-1 TestThread.run()- Starting... 1 [3066588016] TRACE SlowObject <Thread-1 loop> - ENTER: SlowObject::doSomething() 1 [3074980720] WARN test.TestThread <> - Thread-0 TestThread.run()- Starting... 2 [3074980720] TRACE SlowObject <Thread-0 loop> - ENTER: SlowObject::doSomething() 3 [3049802608] INFO SlowObject <Thread-3 loop> - Actually doing something...1, 2, 3, testing...DONE 3 [3058195312] INFO SlowObject <Thread-2 loop> - Actually doing something... 3 [3049802608] TRACE SlowObject <Thread-3 loop> - EXIT: SlowObject::doSomething() 3 [3049802608] TRACE SlowObject <Thread-3 loop> - ENTER: SlowObject::doSomething() 3 [3058195312] INFO SlowObject <Thread-2 loop> - Actually doing something...1, 2, 3, testing...DONE 3 [3066588016] INFO SlowObject <Thread-1 loop> - Actually doing something... The part in the <> seems to contain the thread name set in tests/thread_test/main.cxx line 100. Looking at layout.cxx a line in this layout starts with timestamp, has some thread info in square brackets, log level, logger name, NDC in <> and finally the message itself. This looks a little different than the example output on http://log4cplus.sourceforge.net/docs/html/classlog4cplus_1_1TTCCLayout.html which seems to have no number in square brackets but some name and no <> at all. What's the number in the square brackets? This question aims how I can set some kind of thread name without using the log4cplus thread class which is displayed with TTCC layout (or maybe PatternLayout), but maybe I should understand the example first. Greets Alex -- »With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 *** |
|
From: Václav Z. <vha...@gm...> - 2013-05-01 20:25:32
|
Hi.
I have released log4cplus 1.1.1. The difference between 1.1.1 and
1.1.1-RC4 is small. Here is a full change log for 1.1.1 since the first
release candidate:
log4cplus 1.1.1
- FileAppender - Accept also std::ios_base::ate as "append to a log
file" specification.
log4cplus 1.1.1-RC4
- Fixed bug #156 - Messages are truncated when produced using the
LOG4CPLUS_*_FMT() macros.
- Fixed bug #157 - Fedora package build failure.
- Improved log4cplus initialization:
- Use APC to initialize log4cplus outside loader lock.
- Use Microsoft C runtime library TLS callbacks to initialize
log4cplus as static library.
- Warn during compilation that automatic initialization is not
possible when log4cplus is being compiled with static Microsoft C
runtime library.
- Provide log4cplus::initialize() function to allow users to
initialize log4cplus in situations where automatic initialization
is not possible.
- Several improvements to CMake build:
- Fixed OpenBSD + CMake builds.
- Fixed issues with Visual Studio 2005 CMake builds.
- Added support for CMake builds on Android with NDK. (Sergey
Nikulov)
- The defines.hxx.cmake file is now generated out of defines.hxx.in.
- Library version is parsed out of version.h. (Sergey Nikulov)
- MDC formatter for PatternLayout ("%X") now expands into list of key
value pairs if no specific key is given. (Yaqian Shen)
- Avoid clock_nanosleep() on Android.
- ServerSocket::accept() can now be interrupted from another thread
using new function ServerSocket::interruptAccept().
log4cplus 1.1.1-RC3
- Fixed another MinGW related build failure.
- Fixed mismatched #if/#endif in Windows builds.
log4cplus 1.1.1-RC2
- Allow to disable TLS usage in macros through
LOG4CPLUS_MACRO_DISABLE_TLS preprocessor symbol.
- Fixed compilation with Clang on Cygwin.
- Fixed SIGSEGV when built with some MinGW distributions.
- Fixed build failure when using -march=i386.
- Implemented thread callback to initialize log4cplus for Visual
Studio builds of static library.
- Fixed bug #154 - getHostname() failure because of uninitialized
WinSock.
- Fixed detection of C++11 thread_local keyword.
- Fixed builds using DevKit-tdm-32-4.5.2-20111229-1559.
log4cplus 1.1.1-RC1
- Improved documentation for various classes.
- Cherry-picked various small improvements from trunk.
- Fixed Unicode builds on *NIX.
- Fixed static library builds from Visual Studio project.
- Suppressed warning C4127 from MSVC. (Chris Steenwyk)
- Improved MinGW32 and MinGW64 toolchains compatiblity.
- Fixed encoding handling in Properties class.
- Added include directive for properties files. (Jukka Lantto)
- Added colored output for Win32ConsoleAppender. (Konstantin Baumann)
- (Re)Introduced support for C++Builder (XE3)
- Reimplemented acceptSocket() using select() on Windows to allow
interrupting the accept() call from different thread.
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: Václav Z. <vha...@gm...> - 2013-03-30 19:41:18
|
Hi.
I have released log4cplus 1.1.1-RC4. This is mostly a bug fix release
but there are also some small new features.
- Fixed bug #156 - Messages are truncated when produced using the
LOG4CPLUS_*_FMT() macros.
- Fixed bug #157 - Fedora package build failure.
- Improved log4cplus initialization:
- Use APC to initialize log4cplus outside loader lock.
- Use Microsoft C runtime library TLS callbacks to initialize
log4cplus as static library.
- Warn during compilation that automatic initialization is not
possible when log4cplus is being compiled with static Microsoft C
runtime library.
- Provide log4cplus::initialize() function to allow users to
initialize log4cplus in situations where automatic initialization
is not possible.
- Several improvements to CMake build:
- Fixed OpenBSD + CMake builds.
- Fixed issues with Visual Studio 2005 CMake builds.
- Added support for CMake builds on Android with NDK. (Sergey
Nikulov)
- The defines.hxx.cmake file is now generated out of defines.hxx.in.
- Library version is parsed out of version.h. (Sergey Nikulov)
- MDC formatter for PatternLayout ("%X") now expands into list of key
value pairs if no specific key is given. (Yaqian Shen)
- Avoid clock_nanosleep() on Android.
- ServerSocket::accept() can now be interrupted from another thread
using new function ServerSocket::interruptAccept().
--
VZ
|
|
From: 丘霖(trodylink) <tro...@gm...> - 2013-03-05 06:07:46
|
Every time before call DailyRollingFileAppender::calculateNextRolloverTime, Log4cplus framwork should adjust the parameter "const Time& t" like what is done in method DailyRollingFileAppender::init. Otherwise the log file will NOT be written in HOURLY( if the schedule is set to HOURLY). For example, application starting running at 9:03 AM, and writes a log "AAAA". At 10:30 AM, it writes another log "BBBB". Then nextRolloverTime will be 11:30AM. NOT 11:00AM. So I think this is a bug. |
|
From: Václav Z. <vha...@gm...> - 2013-02-26 18:38:05
|
Hi.
I have released log4cplus 1.0.4.3. It is a minor release fixing two
issues found on Solaris with Solaris Studio.
- Fixed bug #125 - Build failure with Solaris Studio on Solaris,
threading detection problem.
- Fixed bug #161 - Compilation problem due to missing towupper() and
towlower() in global namespace.
--
VZ
|
|
From: Václav Z. <vha...@gm...> - 2013-01-29 07:14:19
|
On 01/29/2013 07:14 AM, sharus wrote:
> hi:
> log4cplus-1.1.1-rc1 find memory leak when using MFC,
> have some one met the problem?
This is likely the thread-local storage that log4cplus uses. If you are
using log4cplus as DLL, then everything will be freed through DllMain(),
which might be after MFC dumps the leaks list. If you are using
log4cplus as a static library, then it is your responsibility to call
log4cplus::threadCleanup() for each thread except the main() thread.
This should probably be documented slightly better than just in
config.hxx as a comment.
>
> Detected memory leaks!
> Dumping objects ->
> {1023} normal block at 0x0380C098, 512 bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> {1022} normal block at 0x0380C050, 8 bytes long.
> Data: < > DC B5 80 03 00 00 00 00
> {1021} normal block at 0x0380C008, 8 bytes long.
> Data: < > B0 B5 80 03 00 00 00 00
> {1020} normal block at 0x0380BFC0, 8 bytes long.
> Data: < > 90 B5 80 03 00 00 00 00
> {1019} normal block at 0x0380BF78, 8 bytes long.
> Data: <` > 60 B5 80 03 00 00 00 00
> {1018} normal block at 0x0380BF30, 8 bytes long.
> Data: <@ > 40 B5 80 03 00 00 00 00
> {1017} normal block at 0x0380BEA0, 80 bytes long.
> Data: < > A0 BE 80 03 A0 BE 80 03 A0 BE 80 03 CD CD CD CD
> {1016} normal block at 0x0380BE58, 8 bytes long.
> Data: <, > 2C B5 80 03 00 00 00 00
> {1015} normal block at 0x0380BE10, 8 bytes long.
> Data: < > 0C B5 80 03 00 00 00 00
> {1014} normal block at 0x0380BDC8, 8 bytes long.
> Data: < > E8 B4 80 03 00 00 00 00
> {1013} normal block at 0x0380BD80, 8 bytes long.
> Data: < > C8 B4 80 03 00 00 00 00
> {1012} normal block at 0x0380BD38, 8 bytes long.
> Data: < > A0 B4 80 03 00 00 00 00
> {1011} normal block at 0x0380BCF0, 8 bytes long.
> Data: < > 80 B4 80 03 00 00 00 00
> {1010} normal block at 0x0380BCA8, 8 bytes long.
> Data: <` > 60 B4 80 03 00 00 00 00
> {1009} normal block at 0x0380BC60, 8 bytes long.
> Data: <@ > 40 B4 80 03 00 00 00 00
> {1005} normal block at 0x0380BB40, 8 bytes long.
> Data: < > 8C B3 80 03 00 00 00 00
> {1004} normal block at 0x0380BAF8, 8 bytes long.
> Data: <l > 6C B3 80 03 00 00 00 00
> {1003} normal block at 0x0380BAB0, 8 bytes long.
> Data: <L > 4C B3 80 03 00 00 00 00
> {1002} normal block at 0x0380BA68, 8 bytes long.
> Data: <, > 2C B3 80 03 00 00 00 00
> {1001} normal block at 0x0380BA20, 8 bytes long.
> Data: < > 0C B3 80 03 00 00 00 00
> {1000} normal block at 0x0380B9D8, 8 bytes long.
> Data: < > EC B2 80 03 00 00 00 00
> {999} normal block at 0x0380B990, 8 bytes long.
> Data: < > CC B2 80 03 00 00 00 00
> {998} normal block at 0x0380B948, 8 bytes long.
> Data: < > AC B2 80 03 00 00 00 00
> {997} normal block at 0x0380B900, 8 bytes long.
> Data: < > 8C B2 80 03 00 00 00 00
> {996} normal block at 0x0380B870, 80 bytes long.
> Data: <p p p > 70 B8 80 03 70 B8 80 03 70 B8 80 03 CD CD CD CD
> {995} normal block at 0x0380B828, 8 bytes long.
> Data: <x > 78 B2 80 03 00 00 00 00
> {994} normal block at 0x0380B7E0, 8 bytes long.
> Data: <` > 60 B2 80 03 00 00 00 00
> {987} normal block at 0x0380B130, 1216 bytes long.
> Data: < 6 6 p > 8C F2 36 00 FC EE 36 00 70 B6 80 03 00 00 00 00
> {985} normal block at 0x0380ACA0, 512 bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> {984} normal block at 0x0380AC58, 8 bytes long.
> Data: < > E4 A1 80 03 00 00 00 00
> {983} normal block at 0x0380AC10, 8 bytes long.
> Data: < > B8 A1 80 03 00 00 00 00
> {982} normal block at 0x0380ABC8, 8 bytes long.
> Data: < > 98 A1 80 03 00 00 00 00
> {981} normal block at 0x0380AB80, 8 bytes long.
> Data: <h > 68 A1 80 03 00 00 00 00
> {980} normal block at 0x0380AB38, 8 bytes long.
> Data: <H > 48 A1 80 03 00 00 00 00
> {979} normal block at 0x0380AAA8, 80 bytes long.
> Data: < > A8 AA 80 03 A8 AA 80 03 A8 AA 80 03 CD CD CD CD
> {978} normal block at 0x0380AA60, 8 bytes long.
> Data: <4 > 34 A1 80 03 00 00 00 00
> {977} normal block at 0x0380AA18, 8 bytes long.
> Data: < > 14 A1 80 03 00 00 00 00
> {976} normal block at 0x0380A9D0, 8 bytes long.
> Data: < > F0 A0 80 03 00 00 00 00
> {975} normal block at 0x0380A988, 8 bytes long.
> Data: < > D0 A0 80 03 00 00 00 00
> {974} normal block at 0x0380A940, 8 bytes long.
> Data: < > A8 A0 80 03 00 00 00 00
> {973} normal block at 0x0380A8F8, 8 bytes long.
> Data: < > 88 A0 80 03 00 00 00 00
> {972} normal block at 0x0380A8B0, 8 bytes long.
> Data: <h > 68 A0 80 03 00 00 00 00
> {971} normal block at 0x0380A868, 8 bytes long.
> Data: <H > 48 A0 80 03 00 00 00 00
> {967} normal block at 0x0380A748, 8 bytes long.
> Data: < > 94 9F 80 03 00 00 00 00
> {966} normal block at 0x0380A700, 8 bytes long.
> Data: <t > 74 9F 80 03 00 00 00 00
> {965} normal block at 0x0380A6B8, 8 bytes long.
> Data: <T > 54 9F 80 03 00 00 00 00
> {964} normal block at 0x0380A670, 8 bytes long.
> Data: <4 > 34 9F 80 03 00 00 00 00
> {963} normal block at 0x0380A628, 8 bytes long.
> Data: < > 14 9F 80 03 00 00 00 00
> {962} normal block at 0x0380A5E0, 8 bytes long.
> Data: < > F4 9E 80 03 00 00 00 00
> {961} normal block at 0x0380A598, 8 bytes long.
> Data: < > D4 9E 80 03 00 00 00 00
> {960} normal block at 0x0380A550, 8 bytes long.
> Data: < > B4 9E 80 03 00 00 00 00
> {959} normal block at 0x0380A508, 8 bytes long.
> Data: < > 94 9E 80 03 00 00 00 00
> {958} normal block at 0x0380A478, 80 bytes long.
> Data: <x x x > 78 A4 80 03 78 A4 80 03 78 A4 80 03 CD CD CD CD
> {957} normal block at 0x0380A430, 8 bytes long.
> Data: < > 80 9E 80 03 00 00 00 00
> {956} normal block at 0x0380A3E8, 8 bytes long.
> Data: <h > 68 9E 80 03 00 00 00 00
> {949} normal block at 0x03809D38, 1216 bytes long.
> Data: < 6 6 x > 8C F2 36 00 FC EE 36 00 78 A2 80 03 00 00 00 00
> {947} normal block at 0x038098A8, 512 bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> {946} normal block at 0x03809860, 8 bytes long.
> Data: <, > 2C 8E 80 03 00 00 00 00
> {945} normal block at 0x03809818, 8 bytes long.
> Data: < > 00 8E 80 03 00 00 00 00
> {944} normal block at 0x038097D0, 8 bytes long.
> Data: < > E0 8D 80 03 00 00 00 00
> {943} normal block at 0x03809788, 8 bytes long.
> Data: < > B0 8D 80 03 00 00 00 00
> {942} normal block at 0x03809740, 8 bytes long.
> Data: < > 90 8D 80 03 00 00 00 00
> {941} normal block at 0x038096B0, 80 bytes long.
> Data: < > B0 96 80 03 B0 96 80 03 B0 96 80 03 CD CD CD CD
> {940} normal block at 0x03809668, 8 bytes long.
> Data: <| > 7C 8D 80 03 00 00 00 00
> {939} normal block at 0x03809620, 8 bytes long.
> Data: <\ > 5C 8D 80 03 00 00 00 00
> {938} normal block at 0x038095D8, 8 bytes long.
> Data: <8 > 38 8D 80 03 00 00 00 00
> {937} normal block at 0x03809590, 8 bytes long.
> Data: < > 18 8D 80 03 00 00 00 00
> {936} normal block at 0x03809548, 8 bytes long.
> Data: < > F0 8C 80 03 00 00 00 00
> {935} normal block at 0x03809500, 8 bytes long.
> Data: < > D0 8C 80 03 00 00 00 00
> {934} normal block at 0x038094B8, 8 bytes long.
> Data: < > B0 8C 80 03 00 00 00 00
> {933} normal block at 0x03809470, 8 bytes long.
> Data: < > 90 8C 80 03 00 00 00 00
> {929} normal block at 0x03809350, 8 bytes long.
> Data: < > DC 8B 80 03 00 00 00 00
> {928} normal block at 0x03809308, 8 bytes long.
> Data: < > BC 8B 80 03 00 00 00 00
> {927} normal block at 0x038092C0, 8 bytes long.
> Data: < > 9C 8B 80 03 00 00 00 00
> {926} normal block at 0x03809278, 8 bytes long.
> Data: <| > 7C 8B 80 03 00 00 00 00
> {925} normal block at 0x03809230, 8 bytes long.
> Data: <\ > 5C 8B 80 03 00 00 00 00
> {924} normal block at 0x038091E8, 8 bytes long.
> Data: << > 3C 8B 80 03 00 00 00 00
> {923} normal block at 0x038091A0, 8 bytes long.
> Data: < > 1C 8B 80 03 00 00 00 00
> {922} normal block at 0x03809158, 8 bytes long.
> Data: < > FC 8A 80 03 00 00 00 00
> {921} normal block at 0x03809110, 8 bytes long.
> Data: < > DC 8A 80 03 00 00 00 00
> {920} normal block at 0x03809080, 80 bytes long.
> Data: < > 80 90 80 03 80 90 80 03 80 90 80 03 CD CD CD CD
> {919} normal block at 0x03809038, 8 bytes long.
> Data: < > C8 8A 80 03 00 00 00 00
> {918} normal block at 0x03808FF0, 8 bytes long.
> Data: < > B0 8A 80 03 00 00 00 00
> {911} normal block at 0x03808980, 1216 bytes long.
> Data: < 6 6 > 8C F2 36 00 FC EE 36 00 80 8E 80 03 00 00 00 00
> Object dump complete.
--
VZ
|
|
From: sharus <sh...@12...> - 2013-01-29 06:14:39
|
hi:
log4cplus-1.1.1-rc1 find memory leak when using MFC,
have some one met the problem?
Detected memory leaks!
Dumping objects ->
{1023} normal block at 0x0380C098, 512 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{1022} normal block at 0x0380C050, 8 bytes long.
Data: < > DC B5 80 03 00 00 00 00
{1021} normal block at 0x0380C008, 8 bytes long.
Data: < > B0 B5 80 03 00 00 00 00
{1020} normal block at 0x0380BFC0, 8 bytes long.
Data: < > 90 B5 80 03 00 00 00 00
{1019} normal block at 0x0380BF78, 8 bytes long.
Data: <` > 60 B5 80 03 00 00 00 00
{1018} normal block at 0x0380BF30, 8 bytes long.
Data: <@ > 40 B5 80 03 00 00 00 00
{1017} normal block at 0x0380BEA0, 80 bytes long.
Data: < > A0 BE 80 03 A0 BE 80 03 A0 BE 80 03 CD CD CD CD
{1016} normal block at 0x0380BE58, 8 bytes long.
Data: <, > 2C B5 80 03 00 00 00 00
{1015} normal block at 0x0380BE10, 8 bytes long.
Data: < > 0C B5 80 03 00 00 00 00
{1014} normal block at 0x0380BDC8, 8 bytes long.
Data: < > E8 B4 80 03 00 00 00 00
{1013} normal block at 0x0380BD80, 8 bytes long.
Data: < > C8 B4 80 03 00 00 00 00
{1012} normal block at 0x0380BD38, 8 bytes long.
Data: < > A0 B4 80 03 00 00 00 00
{1011} normal block at 0x0380BCF0, 8 bytes long.
Data: < > 80 B4 80 03 00 00 00 00
{1010} normal block at 0x0380BCA8, 8 bytes long.
Data: <` > 60 B4 80 03 00 00 00 00
{1009} normal block at 0x0380BC60, 8 bytes long.
Data: <@ > 40 B4 80 03 00 00 00 00
{1005} normal block at 0x0380BB40, 8 bytes long.
Data: < > 8C B3 80 03 00 00 00 00
{1004} normal block at 0x0380BAF8, 8 bytes long.
Data: <l > 6C B3 80 03 00 00 00 00
{1003} normal block at 0x0380BAB0, 8 bytes long.
Data: <L > 4C B3 80 03 00 00 00 00
{1002} normal block at 0x0380BA68, 8 bytes long.
Data: <, > 2C B3 80 03 00 00 00 00
{1001} normal block at 0x0380BA20, 8 bytes long.
Data: < > 0C B3 80 03 00 00 00 00
{1000} normal block at 0x0380B9D8, 8 bytes long.
Data: < > EC B2 80 03 00 00 00 00
{999} normal block at 0x0380B990, 8 bytes long.
Data: < > CC B2 80 03 00 00 00 00
{998} normal block at 0x0380B948, 8 bytes long.
Data: < > AC B2 80 03 00 00 00 00
{997} normal block at 0x0380B900, 8 bytes long.
Data: < > 8C B2 80 03 00 00 00 00
{996} normal block at 0x0380B870, 80 bytes long.
Data: <p p p > 70 B8 80 03 70 B8 80 03 70 B8 80 03 CD CD CD CD
{995} normal block at 0x0380B828, 8 bytes long.
Data: <x > 78 B2 80 03 00 00 00 00
{994} normal block at 0x0380B7E0, 8 bytes long.
Data: <` > 60 B2 80 03 00 00 00 00
{987} normal block at 0x0380B130, 1216 bytes long.
Data: < 6 6 p > 8C F2 36 00 FC EE 36 00 70 B6 80 03 00 00 00 00
{985} normal block at 0x0380ACA0, 512 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{984} normal block at 0x0380AC58, 8 bytes long.
Data: < > E4 A1 80 03 00 00 00 00
{983} normal block at 0x0380AC10, 8 bytes long.
Data: < > B8 A1 80 03 00 00 00 00
{982} normal block at 0x0380ABC8, 8 bytes long.
Data: < > 98 A1 80 03 00 00 00 00
{981} normal block at 0x0380AB80, 8 bytes long.
Data: <h > 68 A1 80 03 00 00 00 00
{980} normal block at 0x0380AB38, 8 bytes long.
Data: <H > 48 A1 80 03 00 00 00 00
{979} normal block at 0x0380AAA8, 80 bytes long.
Data: < > A8 AA 80 03 A8 AA 80 03 A8 AA 80 03 CD CD CD CD
{978} normal block at 0x0380AA60, 8 bytes long.
Data: <4 > 34 A1 80 03 00 00 00 00
{977} normal block at 0x0380AA18, 8 bytes long.
Data: < > 14 A1 80 03 00 00 00 00
{976} normal block at 0x0380A9D0, 8 bytes long.
Data: < > F0 A0 80 03 00 00 00 00
{975} normal block at 0x0380A988, 8 bytes long.
Data: < > D0 A0 80 03 00 00 00 00
{974} normal block at 0x0380A940, 8 bytes long.
Data: < > A8 A0 80 03 00 00 00 00
{973} normal block at 0x0380A8F8, 8 bytes long.
Data: < > 88 A0 80 03 00 00 00 00
{972} normal block at 0x0380A8B0, 8 bytes long.
Data: <h > 68 A0 80 03 00 00 00 00
{971} normal block at 0x0380A868, 8 bytes long.
Data: <H > 48 A0 80 03 00 00 00 00
{967} normal block at 0x0380A748, 8 bytes long.
Data: < > 94 9F 80 03 00 00 00 00
{966} normal block at 0x0380A700, 8 bytes long.
Data: <t > 74 9F 80 03 00 00 00 00
{965} normal block at 0x0380A6B8, 8 bytes long.
Data: <T > 54 9F 80 03 00 00 00 00
{964} normal block at 0x0380A670, 8 bytes long.
Data: <4 > 34 9F 80 03 00 00 00 00
{963} normal block at 0x0380A628, 8 bytes long.
Data: < > 14 9F 80 03 00 00 00 00
{962} normal block at 0x0380A5E0, 8 bytes long.
Data: < > F4 9E 80 03 00 00 00 00
{961} normal block at 0x0380A598, 8 bytes long.
Data: < > D4 9E 80 03 00 00 00 00
{960} normal block at 0x0380A550, 8 bytes long.
Data: < > B4 9E 80 03 00 00 00 00
{959} normal block at 0x0380A508, 8 bytes long.
Data: < > 94 9E 80 03 00 00 00 00
{958} normal block at 0x0380A478, 80 bytes long.
Data: <x x x > 78 A4 80 03 78 A4 80 03 78 A4 80 03 CD CD CD CD
{957} normal block at 0x0380A430, 8 bytes long.
Data: < > 80 9E 80 03 00 00 00 00
{956} normal block at 0x0380A3E8, 8 bytes long.
Data: <h > 68 9E 80 03 00 00 00 00
{949} normal block at 0x03809D38, 1216 bytes long.
Data: < 6 6 x > 8C F2 36 00 FC EE 36 00 78 A2 80 03 00 00 00 00
{947} normal block at 0x038098A8, 512 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{946} normal block at 0x03809860, 8 bytes long.
Data: <, > 2C 8E 80 03 00 00 00 00
{945} normal block at 0x03809818, 8 bytes long.
Data: < > 00 8E 80 03 00 00 00 00
{944} normal block at 0x038097D0, 8 bytes long.
Data: < > E0 8D 80 03 00 00 00 00
{943} normal block at 0x03809788, 8 bytes long.
Data: < > B0 8D 80 03 00 00 00 00
{942} normal block at 0x03809740, 8 bytes long.
Data: < > 90 8D 80 03 00 00 00 00
{941} normal block at 0x038096B0, 80 bytes long.
Data: < > B0 96 80 03 B0 96 80 03 B0 96 80 03 CD CD CD CD
{940} normal block at 0x03809668, 8 bytes long.
Data: <| > 7C 8D 80 03 00 00 00 00
{939} normal block at 0x03809620, 8 bytes long.
Data: <\ > 5C 8D 80 03 00 00 00 00
{938} normal block at 0x038095D8, 8 bytes long.
Data: <8 > 38 8D 80 03 00 00 00 00
{937} normal block at 0x03809590, 8 bytes long.
Data: < > 18 8D 80 03 00 00 00 00
{936} normal block at 0x03809548, 8 bytes long.
Data: < > F0 8C 80 03 00 00 00 00
{935} normal block at 0x03809500, 8 bytes long.
Data: < > D0 8C 80 03 00 00 00 00
{934} normal block at 0x038094B8, 8 bytes long.
Data: < > B0 8C 80 03 00 00 00 00
{933} normal block at 0x03809470, 8 bytes long.
Data: < > 90 8C 80 03 00 00 00 00
{929} normal block at 0x03809350, 8 bytes long.
Data: < > DC 8B 80 03 00 00 00 00
{928} normal block at 0x03809308, 8 bytes long.
Data: < > BC 8B 80 03 00 00 00 00
{927} normal block at 0x038092C0, 8 bytes long.
Data: < > 9C 8B 80 03 00 00 00 00
{926} normal block at 0x03809278, 8 bytes long.
Data: <| > 7C 8B 80 03 00 00 00 00
{925} normal block at 0x03809230, 8 bytes long.
Data: <\ > 5C 8B 80 03 00 00 00 00
{924} normal block at 0x038091E8, 8 bytes long.
Data: << > 3C 8B 80 03 00 00 00 00
{923} normal block at 0x038091A0, 8 bytes long.
Data: < > 1C 8B 80 03 00 00 00 00
{922} normal block at 0x03809158, 8 bytes long.
Data: < > FC 8A 80 03 00 00 00 00
{921} normal block at 0x03809110, 8 bytes long.
Data: < > DC 8A 80 03 00 00 00 00
{920} normal block at 0x03809080, 80 bytes long.
Data: < > 80 90 80 03 80 90 80 03 80 90 80 03 CD CD CD CD
{919} normal block at 0x03809038, 8 bytes long.
Data: < > C8 8A 80 03 00 00 00 00
{918} normal block at 0x03808FF0, 8 bytes long.
Data: < > B0 8A 80 03 00 00 00 00
{911} normal block at 0x03808980, 1216 bytes long.
Data: < 6 6 > 8C F2 36 00 FC EE 36 00 80 8E 80 03 00 00 00 00
Object dump complete. |
|
From: Václav Z. <vha...@gm...> - 2013-01-24 14:25:07
|
On 24 January 2013 13:14, Paolino Marmolaro wrote:
> Hi all,
Hi.
>
> in my logfiles I have the timestamp with 1 hour back.
> How to set the correct time zone?
>
> I'm not using a properties file but managing in C++ code, ie:
>
> log4cplus::PatternLayout *pl = new log4cplus::PatternLayout("%d{%d-%m-%Y
> %H:%M:%S.%q}[%-5t] %-5p: %m%n");
Here, use %D{} (local time) instead of %d{} (UTC). See
http://log4cplus.sourceforge.net/docs/html/classlog4cplus_1_1PatternLayout.html
for more detail on pattern layout format.
--
VZ
|
|
From: Paolino M. <pao...@gm...> - 2013-01-24 12:15:04
|
Hi all,
in my logfiles I have the timestamp with 1 hour back.
How to set the correct time zone?
I'm not using a properties file but managing in C++ code, ie:
log4cplus::PatternLayout *pl = new log4cplus::PatternLayout("%d{%d-%m-%Y
%H:%M:%S.%q}[%-5t] %-5p: %m%n");
...
thanks
pm
|
|
From: Václav Z. <vha...@gm...> - 2013-01-23 18:30:03
|
Hi. I have released log4cplus 1.1.1-RC3. It contains more fixes related to portability to MinGW and most importantly, a fix to broken Windows builds. - Fixed another MinGW related build failure. - Fixed mismatched #if/#endif in Windows builds. -- VZ |
|
From: Václav Z. <vha...@gm...> - 2013-01-16 20:58:08
|
Hi. I have released log4cplus 1.1.1-RC2. It contains several MinGW related fixes and some other changes. - Allow to disable TLS usage in macros through LOG4CPLUS_MACRO_DISABLE_TLS preprocessor symbol. - Fixed compilation with Clang on Cygwin. - Fixed SIGSEGV when built with some MinGW distributions. - Fixed build failure when using -march=i386. - Implemented thread callback to initialize log4cplus for Visual Studio builds of static library. - Fixed bug #154 - getHostname() failure because of uninitialized WinSock. - Fixed detection of C++11 thread_local keyword. - Fixed builds using DevKit-tdm-32-4.5.2-20111229-1559. -- VZ |
|
From: Václav Z. <vha...@gm...> - 2012-12-23 22:51:50
|
Hi. I have released log4cplus 1.0.4.2. It is a maintenance release that contains only a handful of fixes. Here are additions since 1.0.4.2-RC1: - Update with Automake 1.12.6. - Fixed DllMain() issue with MinGW. -- VZ |
|
From: Václav Z. <vha...@gm...> - 2012-12-18 21:59:32
|
Hi. I have released log4cplus 1.1.1-RC1. It contains some bug fixes and small improvements cherry-picked from trunk branch. See <https://sourceforge.net/projects/log4cplus/files/log4cplus-stable/1.1.1/> for sources. - Improved documentation for various classes. - Cherry-picked various small improvements from trunk. - Fixed Unicode builds on *NIX. - Fixed static library builds from Visual Studio project. - Suppressed warning C4127 from MSVC. (Chris Steenwyk) - Improved MinGW32 and MinGW64 toolchains compatiblity. - Fixed encoding handling in Properties class. - Added include directive for properties files. (Jukka Lantto) - Added colored output for Win32ConsoleAppender. (Konstantin Baumann) - (Re)Introduced support for C++Builder (XE3) - Reimplemented acceptSocket() using select() on Windows to allow interrupting the accept() call from different thread. -- VZ |
|
From: Václav Z. <vha...@gm...> - 2012-12-13 10:55:02
|
On 13 December 2012 10:39, Jukka Tervaskanto wrote: > Hello, > > I am trying to use 32-bit version of the log4cplus in Mac OS 10.7.5, but the > liblog4cplus.dylib is always 64 bit. How can I create the 32-bit version? TBH, I have no idea. I have no access to MacOS X or knowledge of the system. Can't you use some kind of compiler flag and pass it to the configure script? (...) So I have searched and it seems you migth get what what you want by adding "-arch i386" to CXXFLAGS (and CFLAGS). E.g., run '$(SRCDIR)/configure CXXFLAGS="-arch i386" CFLAGS="-arch i386"'. -- VZ |
|
From: Václav Z. <vha...@gm...> - 2012-11-25 19:27:47
|
I have removed the log4cplus Subversion repository. All of the development, for at least a year now, is happening on Bazaar repository. The Subversion repository is archived in log4cplus-svnrepo.tar.xz, and it is available for download at <http://sourceforge.net/projects/log4cplus/files/log4cplus-svnrepo.tar.xz/download>. -- VZ |
|
From: SourceForge.net <no...@so...> - 2012-11-20 11:23:59
|
Bugs item #3585765, was opened at 2012-11-09 06:27 Message generated for change (Comment added) 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. ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-20 03:23 Message: Ok, my solution does not work at all, I have tested it. However I believe that your solution is prone to a race. There is window where one thread is in a loop but out of select(), checking select()'s return value; second thread successfully does closesocket(); third thread opens a new socket with the same handle value; first thread resumes waiting in the select() but now for a different socket with the same handle value. ---------------------------------------------------------------------- Comment By: Václav Zeman (wilx) Date: 2012-11-19 05:16 Message: I would rather not any select() returned -1 as closed socket. This could hide some actual errors. Instead of your patch I am attaching a different one based on WSAEventSelect(). It is completely untested but it compiles. Do you think you could test it? ---------------------------------------------------------------------- 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-19 13:16:42
|
Bugs item #3585765, was opened at 2012-11-09 06:27 Message generated for change (Comment added) 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. ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-19 05:16 Message: I would rather not any select() returned -1 as closed socket. This could hide some actual errors. Instead of your patch I am attaching a different one based on WSAEventSelect(). It is completely untested but it compiles. Do you think you could test it? ---------------------------------------------------------------------- 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-18 18:52:04
|
Bugs item #3588337, was opened at 2012-11-18 09:01 Message generated for change (Comment added) made by wilx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3588337&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: Fixed Priority: 5 Private: No Submitted By: JanRos (janrosendahl) Assigned to: Václav Zeman (wilx) Summary: Excluded files make applications not build (static library) Initial Comment: With version 1.1.0 and building with provided project files for MS Visual. I found that 'sysappender.cpp' (and also 'sysappender.h', but that is of less imprtance) are exluded from the log4cplusS project. This makes applications using log4cplusS.lib / log4cplusSD.lib not build. Removing 'exclude from project' solves the issue; log4cplus still builds and application as well. ---------------------------------------------------------------------- >Comment By: Václav Zeman (wilx) Date: 2012-11-18 10:52 Message: This should be fixed in Bazaar branch 1.1.x or in trunk. The files is should now be included in the build in both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3588337&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-18 17:02:09
|
Bugs item #3588337, was opened at 2012-11-18 09:01 Message generated for change (Settings changed) made by janrosendahl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3588337&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: JanRos (janrosendahl) Assigned to: Václav Zeman (wilx) >Summary: Excluded files make applications not build (static library) Initial Comment: With version 1.1.0 and building with provided project files for MS Visual. I found that 'sysappender.cpp' (and also 'sysappender.h', but that is of less imprtance) are exluded from the log4cplusS project. This makes applications using log4cplusS.lib / log4cplusSD.lib not build. Removing 'exclude from project' solves the issue; log4cplus still builds and application as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3588337&group_id=40830 |
|
From: SourceForge.net <no...@so...> - 2012-11-18 17:01:29
|
Bugs item #3588337, was opened at 2012-11-18 09:01 Message generated for change (Tracker Item Submitted) made by janrosendahl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3588337&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: JanRos (janrosendahl) Assigned to: Václav Zeman (wilx) Summary: Excluded files make applicatiosn not build Initial Comment: With version 1.1.0 and building with provided project files for MS Visual. I found that 'sysappender.cpp' (and also 'sysappender.h', but that is of less imprtance) are exluded from the log4cplusS project. This makes applications using log4cplusS.lib / log4cplusSD.lib not build. Removing 'exclude from project' solves the issue; log4cplus still builds and application as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3588337&group_id=40830 |
|
From: Serg V. G. <s....@gm...> - 2012-11-16 16:34:47
|
Hello! Here is some links: http://graylog2.org/ http://www.graylog2.org/about/gelf В Пт., 16/11/2012 в 17:27 +0100, Václav Zeman пишет: > On 16 November 2012 16:48, Serg V. Gulko wrote: > > Hello! > > Hi. > > > It is possible to configure log4cplus to use GELF format to > send messages to greylog server? > Probably not because I have no idea what is GELF and greylog. That > said, it should be possible to create a specific appender for this > logging sink. Do you have any pointers at what GELF and greylog are? > > > > -- > VZ > -- Грубый Генька-генератор грозно грыз горох горстями. |
|
From: Václav Z. <vha...@gm...> - 2012-11-16 16:27:32
|
On 16 November 2012 16:48, Serg V. Gulko wrote: > ** > Hello! > Hi. > > It is possible to configure log4cplus to use GELF format to send messages > to greylog server? > Probably not because I have no idea what is GELF and greylog. That said, it should be possible to create a specific appender for this logging sink. Do you have any pointers at what GELF and greylog are? -- VZ |
927 messages has been excluded from this view by a project administrator.
