log4cplus-devel — Mailing list for log4cplus developers

Re: [Log4cplus-devel] Fixes for CMake build files.

[Václav Z. <vha...@gm...>]

On 09/13/2012 01:23 AM, Chernyshev Vyacheslav wrote:
> Hello.
>
> After various unsuccessful attempts to compile log4cplus on OS X from 
> provided autotools-generated configure file using Clang compiler I've 
I wonder what difficulties you have had with the Autotools build system
on MacOS X. I am keen on fixing those as well.

> decided to try CMake build. And it turned out that some configure 
> defines are simply missing. Here are the fixes that I've made. All paths 
> are relative to project's root directory.
I have just recently added a TODO item just for that. :)

>
> 1. ./CMakeLists.txt https://gist.github.com/3710553
>     - added WITH_ICONV option that sets LOG4CPLUS_WITH_ICONV, the same
>       is done when --with-iconv option is provided to configure system.
> 2. ./ConfigureChecks.cmake https://gist.github.com/3710633
>     - added very simple check to find system-provided iconv library, it
>       may be required to use iconv* functions on some systems;
>     - added checks for functions mbstowcs, wcstombs, nanosleep;
>     - added check for __func__ symbol;
>     - iconv* functions will now be checked only when LOG4CPLUS_WITH_ICONV
>       is defined, it mimics behaviour of autotools build system;
>     - added proper checks for DECLSPEC_EXPORT/IMPORT/PRIVATE, taken from
>       autotools files;
>     - added thread-local support detection;
>     - added C++11 atomics detection.
> 3. ./src/CMakeLists.txt https://gist.github.com/3710658
>     - link iconv library if it is required to use iconv* functions and
>       iconv support was requested.
> 4. ./include/log4cplus/config/defines.hxx.cmake.in
>     https://gist.github.com/3710667
>     - added missing defines to make it on par with defines.hxx.in.
I have applied all of the patches to both trunk and 1.1.x  branch.

>
> There are additional things to tweak in CMake files, but it can be 
> discussed later.
Feel free to send more patches to improve MacOS X support. I have no way
of testing log4cplus for it.


-- 
VZ

[Log4cplus-devel] Fixes for CMake build files.

[Chernyshev V. <ast...@ro...>]

Hello.

After various unsuccessful attempts to compile log4cplus on OS X from 
provided autotools-generated configure file using Clang compiler I've 
decided to try CMake build. And it turned out that some configure 
defines are simply missing. Here are the fixes that I've made. All paths 
are relative to project's root directory.

1. ./CMakeLists.txt https://gist.github.com/3710553
    - added WITH_ICONV option that sets LOG4CPLUS_WITH_ICONV, the same
      is done when --with-iconv option is provided to configure system.
2. ./ConfigureChecks.cmake https://gist.github.com/3710633
    - added very simple check to find system-provided iconv library, it
      may be required to use iconv* functions on some systems;
    - added checks for functions mbstowcs, wcstombs, nanosleep;
    - added check for __func__ symbol;
    - iconv* functions will now be checked only when LOG4CPLUS_WITH_ICONV
      is defined, it mimics behaviour of autotools build system;
    - added proper checks for DECLSPEC_EXPORT/IMPORT/PRIVATE, taken from
      autotools files;
    - added thread-local support detection;
    - added C++11 atomics detection.
3. ./src/CMakeLists.txt https://gist.github.com/3710658
    - link iconv library if it is required to use iconv* functions and
      iconv support was requested.
4. ./include/log4cplus/config/defines.hxx.cmake.in
    https://gist.github.com/3710667
    - added missing defines to make it on par with defines.hxx.in.

There are additional things to tweak in CMake files, but it can be 
discussed later.

[Log4cplus-devel] [ log4cplus-Bugs-3306070 ] CXXFLAGS are ignored by configure

[SourceForge.net <no...@so...>]

Bugs item #3306070, was opened at 2011-05-22 17:44
Message generated for change (Settings changed) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3306070&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.0.4
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Will Mason (will_mason)
Assigned to: Václav Zeman (wilx)
Summary: CXXFLAGS are ignored by configure

Initial Comment:
Log4cplus ignores CXXFLAGS that the user specifies on the configure command line and just sets the ones it wants. This is kind of inconvenient. It would be nice if you let me add the ones I want to the ones that you want. Thank you.

----------------------------------------------------------------------

Comment By: Will Mason (will_mason)
Date: 2012-09-10 07:36

Message:
I just tried this with 1.0.4.2-rc2, and I no longer see the behavior.

What I saw before was that if I invoked ../configure CXXFLAGS=-rdynamic (or
something like that), the log4cplus build would ignore my CXXFLAGS and only
use the ones that it liked.

I no longer see this. It now properly uses both its wanted flags and the
ones I specify.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-09 13:14

Message:
I am not sure that I understand this bug report. Could you be more
specific?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3306070&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3306070 ] CXXFLAGS are ignored by configure

[SourceForge.net <no...@so...>]

Bugs item #3306070, was opened at 2011-05-22 17:44
Message generated for change (Comment added) made by will_mason
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3306070&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.0.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Will Mason (will_mason)
Assigned to: Václav Zeman (wilx)
Summary: CXXFLAGS are ignored by configure

Initial Comment:
Log4cplus ignores CXXFLAGS that the user specifies on the configure command line and just sets the ones it wants. This is kind of inconvenient. It would be nice if you let me add the ones I want to the ones that you want. Thank you.

----------------------------------------------------------------------

>Comment By: Will Mason (will_mason)
Date: 2012-09-10 07:36

Message:
I just tried this with 1.0.4.2-rc2, and I no longer see the behavior.

What I saw before was that if I invoked ../configure CXXFLAGS=-rdynamic (or
something like that), the log4cplus build would ignore my CXXFLAGS and only
use the ones that it liked.

I no longer see this. It now properly uses both its wanted flags and the
ones I specify.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-09 13:14

Message:
I am not sure that I understand this bug report. Could you be more
specific?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3306070&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3306070 ] CXXFLAGS are ignored by configure

[SourceForge.net <no...@so...>]

Bugs item #3306070, was opened at 2011-05-22 17:44
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3306070&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.0.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Will Mason (will_mason)
Assigned to: Václav Zeman (wilx)
Summary: CXXFLAGS are ignored by configure

Initial Comment:
Log4cplus ignores CXXFLAGS that the user specifies on the configure command line and just sets the ones it wants. This is kind of inconvenient. It would be nice if you let me add the ones I want to the ones that you want. Thank you.

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-09 13:14

Message:
I am not sure that I understand this bug report. Could you be more
specific?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3306070&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3196803 ] Requiring STLport on Solaris is problematic

[SourceForge.net <no...@so...>]

Bugs item #3196803, was opened at 2011-03-01 18:44
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3196803&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: Fixed
Priority: 5
Private: No
Submitted By: Will Mason (will_mason)
Assigned to: Václav Zeman (wilx)
Summary: Requiring STLport on Solaris is problematic

Initial Comment:
In your configure.in script you explicitly select the option -library=stlport4 when building with Sun's compiler on Solaris. This is very problematic. Because libtool will pick up those options in builds of downstream products, you have now forced everyone who uses log4cplus also to use STLport, whether they want to or not. I edited your configure script and replaced stlport4 with Cstd, Sun's version of STL, and log4cplus built just fine, as did my product after making this change. It's kind of curious that, in light of the fact that your product does not even require STLport, that you would choose not to use the default library.

I would recommend that you do no select which version of STL your users must use. If I were you, I would not use the -library compiler option at all and just let the compiler choose the default. If a user wants a different library, then they can set the CXXFLAGS and LDLFAGS themselves. The way your configure script is set up, you literally force STLport down everyone's throat.

Thanks for your attention.

And, by the way, I really like your library. It's awesome.

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-09 09:03

Message:
And I have applied a similar patch to 1.0.4.1 branch as well. It is part of
1.0.4.2-RC1 release now.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-09 03:02

Message:
I am documenting the change as follows and I consider it fixed now for
good.

"Solaris Studio compilers' default standard C++ library is very
non-standard.  It seems that it is not conforming enough in, e.g., Sun
C++ 5.12 Linux_i386 2011/11/16 (missing std::time_t, etc.), but it
works well enough on Solaris with Sun C++ 5.8 2005/10/13.  Thus
log4cplus adds -library=stlport4 to the CXXFLAGS environment variable,
unless a switch matching -library=(stlport4|stdcxx4|Cstd) is already
present there.  If you want to override the default supplied by
log4cplus, just set it into CXXFLAGS on configure script command line."

Please test these changes on your platform.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-09 02:29

Message:
I have found out that using -library=Cstd works on some systems (like Sun
OS 5.10, with Sun C++ 5.8 2005/10/13) but does not work on others (like
Linux with Sun C++ 5.12 Linux_i386 2011/11/16). Thus I have made a change
for 1.1.0-RC10, that adds the -library=stlport4 option only if CXXFLAGS
does not yet contain any switch matching -library=(stdcxx4|stlport4|Cstd)
regular expression.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-04-27 01:56

Message:
Just FYI, I have documented the requirement -library=stlport4 for
compilation with Solaris Studio C++ compiler. The Cstd library is simply
not good enough. This will be part of upcoming 1.0.4.1 release.


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-07-16 05:43

Message:
I have removed the -library=stlport4 check from configure.in on
PRODUCTION_1_0_x in the 1562 revision.

----------------------------------------------------------------------

Comment By: Will Mason (will_mason)
Date: 2011-03-02 06:53

Message:
Hi, thanks for the information. Yes, I'm using Sun's latest compiler on
Solaris 11. I know that Sun's STL isn't great, but there are other
considerations in play for some of us. For example, what happens when you
ship your product to an older box that doesn't have the STLport run-time
library?

If you do discover that STLport is required to build log4cplus, please
document this somehow. The problem with the way you are currently doing it
is that this undocumented requirement is appearing as a link option only in
*my* build, thanks to libtool. In order for your library to work correctly,
you also need me to use the -library=stlport4 with my compiler flags, which
your documentation does not state is a requirement. Thus, the resulting
build of my product is broken, since I'm using Sun's STL headers with
log4cplus, but then linking to STLport.

An additional headache for your users is that with your requirement for
STLport, you have now forced my product and every other third-party product
that I use to build with STLport, since we all have to use the same STL
headers at compile time. That seems like a somewhat unrealistic requirement
for a library provider to impose.

Anyway, thanks for your time.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-03-01 22:18

Message:
If I remember correctly log4cplus did not compile at the time. Sun's
compiler's C++ standard library is broken severally. However, I will
recheck on my OpenSolaris VM if it is still a problem even in the default
configuration. If it is not a problem, I will remove that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3196803&group_id=40830

[Log4cplus-devel] log4cplus-1.0.4.2-RC1 released

[Václav Z. <vha...@gm...>]

Hi.

I have released log4cplus 1.0.4.2-RC1. It is a maintenance release that
contains only a handful of compatibility fixes:

- Fixed log4cplus.spec for Fedora builds.

- Added compatibility typedef for return type of LogLog::getLogLog() to
hide differences between 1.0.4.x and 1.1.x releases.

- Improved compatibility with Solaris Studio builds without
'-library=stlport4' option. The '-library=stlport4' option is now added
only if CXXFLAGS is missing any of '-library=(stlport4|stdcxx4|Cstd)'
options.

-- 
VZ

[Log4cplus-devel] [ log4cplus-Bugs-3196803 ] Requiring STLport on Solaris is problematic

[SourceForge.net <no...@so...>]

Bugs item #3196803, was opened at 2011-03-01 18:44
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3196803&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: Fixed
Priority: 5
Private: No
Submitted By: Will Mason (will_mason)
Assigned to: Václav Zeman (wilx)
Summary: Requiring STLport on Solaris is problematic

Initial Comment:
In your configure.in script you explicitly select the option -library=stlport4 when building with Sun's compiler on Solaris. This is very problematic. Because libtool will pick up those options in builds of downstream products, you have now forced everyone who uses log4cplus also to use STLport, whether they want to or not. I edited your configure script and replaced stlport4 with Cstd, Sun's version of STL, and log4cplus built just fine, as did my product after making this change. It's kind of curious that, in light of the fact that your product does not even require STLport, that you would choose not to use the default library.

I would recommend that you do no select which version of STL your users must use. If I were you, I would not use the -library compiler option at all and just let the compiler choose the default. If a user wants a different library, then they can set the CXXFLAGS and LDLFAGS themselves. The way your configure script is set up, you literally force STLport down everyone's throat.

Thanks for your attention.

And, by the way, I really like your library. It's awesome.

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-09 03:02

Message:
I am documenting the change as follows and I consider it fixed now for
good.

"Solaris Studio compilers' default standard C++ library is very
non-standard.  It seems that it is not conforming enough in, e.g., Sun
C++ 5.12 Linux_i386 2011/11/16 (missing std::time_t, etc.), but it
works well enough on Solaris with Sun C++ 5.8 2005/10/13.  Thus
log4cplus adds -library=stlport4 to the CXXFLAGS environment variable,
unless a switch matching -library=(stlport4|stdcxx4|Cstd) is already
present there.  If you want to override the default supplied by
log4cplus, just set it into CXXFLAGS on configure script command line."

Please test these changes on your platform.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-09 02:29

Message:
I have found out that using -library=Cstd works on some systems (like Sun
OS 5.10, with Sun C++ 5.8 2005/10/13) but does not work on others (like
Linux with Sun C++ 5.12 Linux_i386 2011/11/16). Thus I have made a change
for 1.1.0-RC10, that adds the -library=stlport4 option only if CXXFLAGS
does not yet contain any switch matching -library=(stdcxx4|stlport4|Cstd)
regular expression.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-04-27 01:56

Message:
Just FYI, I have documented the requirement -library=stlport4 for
compilation with Solaris Studio C++ compiler. The Cstd library is simply
not good enough. This will be part of upcoming 1.0.4.1 release.


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-07-16 05:43

Message:
I have removed the -library=stlport4 check from configure.in on
PRODUCTION_1_0_x in the 1562 revision.

----------------------------------------------------------------------

Comment By: Will Mason (will_mason)
Date: 2011-03-02 06:53

Message:
Hi, thanks for the information. Yes, I'm using Sun's latest compiler on
Solaris 11. I know that Sun's STL isn't great, but there are other
considerations in play for some of us. For example, what happens when you
ship your product to an older box that doesn't have the STLport run-time
library?

If you do discover that STLport is required to build log4cplus, please
document this somehow. The problem with the way you are currently doing it
is that this undocumented requirement is appearing as a link option only in
*my* build, thanks to libtool. In order for your library to work correctly,
you also need me to use the -library=stlport4 with my compiler flags, which
your documentation does not state is a requirement. Thus, the resulting
build of my product is broken, since I'm using Sun's STL headers with
log4cplus, but then linking to STLport.

An additional headache for your users is that with your requirement for
STLport, you have now forced my product and every other third-party product
that I use to build with STLport, since we all have to use the same STL
headers at compile time. That seems like a somewhat unrealistic requirement
for a library provider to impose.

Anyway, thanks for your time.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-03-01 22:18

Message:
If I remember correctly log4cplus did not compile at the time. Sun's
compiler's C++ standard library is broken severally. However, I will
recheck on my OpenSolaris VM if it is still a problem even in the default
configuration. If it is not a problem, I will remove that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3196803&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3196803 ] Requiring STLport on Solaris is problematic

[SourceForge.net <no...@so...>]

Bugs item #3196803, was opened at 2011-03-01 18:44
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3196803&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: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Will Mason (will_mason)
Assigned to: Václav Zeman (wilx)
Summary: Requiring STLport on Solaris is problematic

Initial Comment:
In your configure.in script you explicitly select the option -library=stlport4 when building with Sun's compiler on Solaris. This is very problematic. Because libtool will pick up those options in builds of downstream products, you have now forced everyone who uses log4cplus also to use STLport, whether they want to or not. I edited your configure script and replaced stlport4 with Cstd, Sun's version of STL, and log4cplus built just fine, as did my product after making this change. It's kind of curious that, in light of the fact that your product does not even require STLport, that you would choose not to use the default library.

I would recommend that you do no select which version of STL your users must use. If I were you, I would not use the -library compiler option at all and just let the compiler choose the default. If a user wants a different library, then they can set the CXXFLAGS and LDLFAGS themselves. The way your configure script is set up, you literally force STLport down everyone's throat.

Thanks for your attention.

And, by the way, I really like your library. It's awesome.

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-09 02:29

Message:
I have found out that using -library=Cstd works on some systems (like Sun
OS 5.10, with Sun C++ 5.8 2005/10/13) but does not work on others (like
Linux with Sun C++ 5.12 Linux_i386 2011/11/16). Thus I have made a change
for 1.1.0-RC10, that adds the -library=stlport4 option only if CXXFLAGS
does not yet contain any switch matching -library=(stdcxx4|stlport4|Cstd)
regular expression.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-04-27 01:56

Message:
Just FYI, I have documented the requirement -library=stlport4 for
compilation with Solaris Studio C++ compiler. The Cstd library is simply
not good enough. This will be part of upcoming 1.0.4.1 release.


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-07-16 05:43

Message:
I have removed the -library=stlport4 check from configure.in on
PRODUCTION_1_0_x in the 1562 revision.

----------------------------------------------------------------------

Comment By: Will Mason (will_mason)
Date: 2011-03-02 06:53

Message:
Hi, thanks for the information. Yes, I'm using Sun's latest compiler on
Solaris 11. I know that Sun's STL isn't great, but there are other
considerations in play for some of us. For example, what happens when you
ship your product to an older box that doesn't have the STLport run-time
library?

If you do discover that STLport is required to build log4cplus, please
document this somehow. The problem with the way you are currently doing it
is that this undocumented requirement is appearing as a link option only in
*my* build, thanks to libtool. In order for your library to work correctly,
you also need me to use the -library=stlport4 with my compiler flags, which
your documentation does not state is a requirement. Thus, the resulting
build of my product is broken, since I'm using Sun's STL headers with
log4cplus, but then linking to STLport.

An additional headache for your users is that with your requirement for
STLport, you have now forced my product and every other third-party product
that I use to build with STLport, since we all have to use the same STL
headers at compile time. That seems like a somewhat unrealistic requirement
for a library provider to impose.

Anyway, thanks for your time.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-03-01 22:18

Message:
If I remember correctly log4cplus did not compile at the time. Sun's
compiler's C++ standard library is broken severally. However, I will
recheck on my OpenSolaris VM if it is still a problem even in the default
configuration. If it is not a problem, I will remove that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3196803&group_id=40830

[Log4cplus-devel] log4cplus 1.1.0-RC9 released

[Václav Z. <vha...@gm...>]

Hi.

I have released log4cplus 1.1.0-RC9. It mainly contains bug fixes:

- 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)

-- 
VZ

[Log4cplus-devel] [ log4cplus-Bugs-3565529 ] Building with VS 2005

[SourceForge.net <no...@so...>]

Bugs item #3565529, was opened at 2012-09-07 06:13
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3565529&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: Fixed
Priority: 6
Private: No
Submitted By: xg00 ()
Assigned to: Václav Zeman (wilx)
Summary: Building with VS 2005

Initial Comment:
Bug applies for log4cplus-1.1.0-rc8, there is error C2712 in syncprims-win32.h.
I've attached patch that fixes this bug.

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-07 07:23

Message:
Never mind, I have missed the C2712 code in the OP. Fixed.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-07 07:08

Message:
I will accept the patch but I would like to know what kind of error you
were getting without it?

----------------------------------------------------------------------

Comment By: xg00 ()
Date: 2012-09-07 06:47

Message:
I forgot to specify, that VS project files gereated with cmake.

Also for VS2005 you need to define _WIN32_WINNT=0x501

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3565529&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3565529 ] Building with VS 2005

[SourceForge.net <no...@so...>]

Bugs item #3565529, was opened at 2012-09-07 06:13
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3565529&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: Remind
>Priority: 6
Private: No
Submitted By: xg00 ()
Assigned to: Václav Zeman (wilx)
Summary: Building with VS 2005

Initial Comment:
Bug applies for log4cplus-1.1.0-rc8, there is error C2712 in syncprims-win32.h.
I've attached patch that fixes this bug.

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-07 07:08

Message:
I will accept the patch but I would like to know what kind of error you
were getting without it?

----------------------------------------------------------------------

Comment By: xg00 ()
Date: 2012-09-07 06:47

Message:
I forgot to specify, that VS project files gereated with cmake.

Also for VS2005 you need to define _WIN32_WINNT=0x501

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3565529&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3565529 ] Building with VS 2005

[SourceForge.net <no...@so...>]

Bugs item #3565529, was opened at 2012-09-07 06:13
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3565529&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: xg00 ()
Assigned to: Václav Zeman (wilx)
Summary: Building with VS 2005

Initial Comment:
Bug applies for log4cplus-1.1.0-rc8, there is error C2712 in syncprims-win32.h.
I've attached patch that fixes this bug.

----------------------------------------------------------------------

>Comment By: xg00 ()
Date: 2012-09-07 06:47

Message:
I forgot to specify, that VS project files gereated with cmake.

Also for VS2005 you need to define _WIN32_WINNT=0x501

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3565529&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3565529 ] Building with VS 2005

[SourceForge.net <no...@so...>]

Bugs item #3565529, was opened at 2012-09-07 06:13
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3565529&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: xg00 ()
Assigned to: Václav Zeman (wilx)
Summary: Building with VS 2005

Initial Comment:
Bug applies for log4cplus-1.1.0-rc8, there is error C2712 in syncprims-win32.h.
I've attached patch that fixes this bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3565529&group_id=40830

Re: [Log4cplus-devel] LOG4CPLUS_DEBUG expansion fails when DEBUG macro is defined

[Václav Z. <vha...@gm...>]

On 5 September 2012 21:53, Chernyshev Vyacheslav wrote:
> Hello.
>
> While testing log4cplus with default-generated Xcode project on OS X,
> I've found out that any usage of LOG4CPLUS_DEBUG immediately produces
> very strange compilation errors. After examing this problem I've noticed
> that Xcode defines DEBUG macro to 1 for debug builds. As LOG4CPLUS_DEBUG
> is defined like:
>      LOG4CPLUS_MACRO_BODY (logger, logEvent, DEBUG)
> it is obvious that expanding this macro will fail later.
>
> I have fixed it this way locally: https://gist.github.com/3643384 It
> somewhat uglifies the code, but predefined DEBUG_LOG_LEVEL macro is much
> less common than DEBUG/NDEBUG macro pairs.
Thank you for the patch. I have applied it together with some small
additional changes.

-- 
VZ

[Log4cplus-devel] [ log4cplus-Support Requests-3560984 ] creating custom log level and setting it from prperty file

[SourceForge.net <no...@so...>]

Support Requests item #3560984, was opened at 2012-08-23 05:12
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3560984&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.0.4
>Status: Closed
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Václav Zeman (wilx)
Summary: creating custom log level and setting it from prperty file

Initial Comment:
Hello,
I am trying to create custom log levels but I have faced these problems:
 1. I am not able to set custom log level from property file, log4cplus crashes (Getting error: log4cplus:ERROR LoggerImpl::getChainedLogLevel()- No valid LogLevel found);
 2. If I set custom log level in my program, then log level in log file is named: UNKNOWN;

Info about log4cplus:
Using static library
Version - 1.0.4
Build system - VisualStudio 2010 (project configuration is Debug)
Windows 7 SP1, 64bit

Config file:
log4cplus.rootLogger=TRACE1, Main
 
log4cplus.appender.Main=log4cplus::RollingFileAppender
log4cplus.appender.Main.File=myLogFile.log 
log4cplus.appender.Main.Append=true
log4cplus.appender.Main.MaxFileSize=10MB
log4cplus.appender.Main.MaxBackupIndex=50
log4cplus.appender.Main.layout=log4cplus::PatternLayout 
log4cplus.appender.Main.layout.ConversionPattern=%d | [%-7p] | %-20c | %-20m |%n 

----------------------------------------------------------------------

>Comment By: https://www.google.com/accounts ()
Date: 2012-09-06 00:52

Message:
You were right about initialization order problem. When I moved calls you
specified to main it worked great. I tested on static library. 
Thanks for help.

----------------------------------------------------------------------

Comment By: https://www.google.com/accounts ()
Date: 2012-08-28 06:38

Message:
I will try your suggestions next week.
Also I have noticed if log level is misspelled, then log4cplus (static
library) crashes with the same error as I have wrote earlier.
Thanks for suggestions.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-27 06:09

Message:
I could not reproduce the problem with log4cplus' test cases. But these
test cases are using log4cplus as a DLL. Could you try your code with
log4cplus as a DLL? Also/alternatively, could you test with the
pushToStringMethod() and pushFromStringMethod() calls moved into main()? I
suspect this might be an instance of static objects initialization order
fiasco problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3560984&group_id=40830

[Log4cplus-devel] LOG4CPLUS_DEBUG expansion fails when DEBUG macro is defined

[Chernyshev V. <ast...@ro...>]

Hello.

While testing log4cplus with default-generated Xcode project on OS X, 
I've found out that any usage of LOG4CPLUS_DEBUG immediately produces 
very strange compilation errors. After examing this problem I've noticed 
that Xcode defines DEBUG macro to 1 for debug builds. As LOG4CPLUS_DEBUG 
is defined like:
     LOG4CPLUS_MACRO_BODY (logger, logEvent, DEBUG)
it is obvious that expanding this macro will fail later.

I have fixed it this way locally: https://gist.github.com/3643384 It 
somewhat uglifies the code, but predefined DEBUG_LOG_LEVEL macro is much 
less common than DEBUG/NDEBUG macro pairs.

[Log4cplus-devel] [ log4cplus-Bugs-3313645 ] Using cmake is impossible on Linux withtout configure step

[SourceForge.net <no...@so...>]

Bugs item #3313645, was opened at 2011-06-08 03:01
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3313645&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: Pending
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Nikita Manovich (nikman84)
Assigned to: Václav Zeman (wilx)
Summary: Using cmake is impossible on Linux withtout configure step

Initial Comment:
I just tried to use cmake to build the product on Linux and got errors (see below). After "./configure" command cmake works. The package does'nt contain  log4cplus/config/defines.hxx but only  log4cplus/config/defines.hxx.in. Thus configure step is mandatory now. Is it possible to fix that (cmake feature is cool)!

[  1%] Building CXX object CMakeFiles/log4cplus.dir/src/appender.cxx.o
/usr/bin/c++   -Dlog4cplus_EXPORTS -fPIC -I/tmp/log4cplus-1.0.4/include   -DINSIDE_LOG4CPLUS -o CMakeFiles/log4cplus.dir/src/appender.cxx.o -c /tmp/log4cplus-1.0.4/src/appender.cxx
In file included from /tmp/log4cplus-1.0.4/include/log4cplus/appender.h:26:0,
                 from /tmp/log4cplus-1.0.4/src/appender.cxx:21:
/tmp/log4cplus-1.0.4/include/log4cplus/config.hxx:33:42: fatal error: log4cplus/config/defines.hxx: No such file or directory
compilation terminated.
make[2]: *** [CMakeFiles/log4cplus.dir/src/appender.cxx.o] Error 1
make[2]: Leaving directory `/tmp/log4cplus-1.0.4/build'
make[1]: *** [CMakeFiles/log4cplus.dir/all] Error 2
make[1]: Leaving directory `/tmp

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-04 03:04

Message:
I believe this is now fixed on 1.1.x branch.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3313645&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3467112 ] ptd_cleanup_func posix segfault

[SourceForge.net <no...@so...>]

Bugs item #3467112, was opened at 2011-12-29 11:58
Message generated for change (Settings changed) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3467112&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: Pending
Resolution: Fixed
Priority: 6
Private: No
Submitted By: rjmyst3 (rjmyst3)
Assigned to: Václav Zeman (wilx)
Summary: ptd_cleanup_func posix segfault

Initial Comment:
changes posix implementation of ptd_cleanup_func's call to internal::get_ptd to pass 'false' to prevent a segfault
also move ptd_cleanup_func to the internal namespace

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-04 02:49

Message:
I think that this is now fixed in 1.1.0 in Bazaar repo on trunk and 1.1.x
branches. See also
https://sourceforge.net/tracker/index.php?func=detail&aid=3563699&group_id=40830&atid=429073#


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-04-29 02:09

Message:
Please could you be more specific about the environment you are working
in?
What OS/CPU are you using?
What compiler and compiler version are you using?
What library kind have you chosen: static library or dynamically linked
library?
What is the configure script command line that you are using to produce
log4cplus binaries?
Please attach config.log, defines.hxx files.
Adding a self contained test case would also help tremendously.


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-04-19 08:50

Message:
Well, I still do not understand the new version of ptd_cleanup_func():

//! Thread local storage clean up function for POSIX threads.
static 
void 
ptd_cleanup_func (void * arg)
{
    // ??? Asserting for NULL return value from get_ptd() does not make
sense to me.
    // ??? The get_ptd(false) invocation should return the per thread data
allocated for this thread.
    // ??? It could be null but need not to be, AFAICS.
    assert (0 == internal::get_ptd (false));
    // ??? This looks ok. However given the assertion above, it would be
no-op.
    // ??? Maybe the assertion above should be assert (0 ==
internal::get_ptd (false) || arg == internal::get_ptd (false));
    // ??? What do you think?
    delete reinterpret_cast<internal::per_thread_data*>(arg);
}

The rest of the patch seems ok.


----------------------------------------------------------------------

Comment By: w0lanto (w0lanto)
Date: 2012-01-11 14:02

Message:
I've test case that's causing segfault. 
I have one thread in which I configure log4cplus via configuration file(
doConfigure method ). 
In this thread later on I'm creating a other thread, and waiting for it to
finish. After the other thread is finished segfault occurs. 
The patch fixes this segfault, thanks rjmyst3!

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-12-29 14:51

Message:
I see the patch but I am not sure that I understand the reasons for it. Do
you have a test case that segfaulting? I understand why it should call
get_ptd (false) in the ptd_cleanup_func() but I do not understand the
reason for splitting the function and the second version of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3467112&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3467112 ] ptd_cleanup_func posix segfault

[SourceForge.net <no...@so...>]

Bugs item #3467112, was opened at 2011-12-29 11:58
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3467112&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: Pending
>Resolution: Fixed
Priority: 6
Private: No
Submitted By: rjmyst3 (rjmyst3)
Assigned to: Václav Zeman (wilx)
Summary: ptd_cleanup_func posix segfault

Initial Comment:
changes posix implementation of ptd_cleanup_func's call to internal::get_ptd to pass 'false' to prevent a segfault
also move ptd_cleanup_func to the internal namespace

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-04 02:49

Message:
I think that this is now fixed in 1.1.0 in Bazaar repo on trunk and 1.1.x
branches. See also
https://sourceforge.net/tracker/index.php?func=detail&aid=3563699&group_id=40830&atid=429073#


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-04-29 02:09

Message:
Please could you be more specific about the environment you are working
in?
What OS/CPU are you using?
What compiler and compiler version are you using?
What library kind have you chosen: static library or dynamically linked
library?
What is the configure script command line that you are using to produce
log4cplus binaries?
Please attach config.log, defines.hxx files.
Adding a self contained test case would also help tremendously.


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-04-19 08:50

Message:
Well, I still do not understand the new version of ptd_cleanup_func():

//! Thread local storage clean up function for POSIX threads.
static 
void 
ptd_cleanup_func (void * arg)
{
    // ??? Asserting for NULL return value from get_ptd() does not make
sense to me.
    // ??? The get_ptd(false) invocation should return the per thread data
allocated for this thread.
    // ??? It could be null but need not to be, AFAICS.
    assert (0 == internal::get_ptd (false));
    // ??? This looks ok. However given the assertion above, it would be
no-op.
    // ??? Maybe the assertion above should be assert (0 ==
internal::get_ptd (false) || arg == internal::get_ptd (false));
    // ??? What do you think?
    delete reinterpret_cast<internal::per_thread_data*>(arg);
}

The rest of the patch seems ok.


----------------------------------------------------------------------

Comment By: w0lanto (w0lanto)
Date: 2012-01-11 14:02

Message:
I've test case that's causing segfault. 
I have one thread in which I configure log4cplus via configuration file(
doConfigure method ). 
In this thread later on I'm creating a other thread, and waiting for it to
finish. After the other thread is finished segfault occurs. 
The patch fixes this segfault, thanks rjmyst3!

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-12-29 14:51

Message:
I see the patch but I am not sure that I understand the reasons for it. Do
you have a test case that segfaulting? I understand why it should call
get_ptd (false) in the ptd_cleanup_func() but I do not understand the
reason for splitting the function and the second version of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3467112&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3174236 ] Compilation of liblog4cplus 1.0.5 (HEAD) failed on Solaris 8

[SourceForge.net <no...@so...>]

Bugs item #3174236, was opened at 2011-02-06 07:25
Message generated for change (Settings changed) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3174236&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: Pending
Resolution: Accepted
>Priority: 4
Private: No
Submitted By: Mikael Tintinger (mtintinger)
Assigned to: Václav Zeman (wilx)
Summary: Compilation of liblog4cplus 1.0.5 (HEAD) failed on Solaris 8

Initial Comment:
libtool: compile:  CC -DHAVE_CONFIG_H -DINSIDE_LOG4CPLUS -I../include -I../include -DNDEBUG -DUNICODE -D_REENTRANT -g +w -library=stlport4 -library=Crun -D_REENTRANT -c stringhelper.cxx  -KPIC -DPIC -o .libs/stringhelper.o
"stringhelper.cxx", line 360: Error: towupper is not a member of file level.
"stringhelper.cxx", line 378: Error: towlower is not a member of file level.

To build the library I have to launch ./configure CFLAGS=-DUNICODE CPPFLAGS=-DUNICODE
and include <wchar.h> for towupper and towlower functions in stringhelper.cxx.

Is it possible to make UNICODE an option as it is for REENTRANT (enable-threads) ?


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-03 22:33

Message:
Is this fixed for you in the 1.1.0 series?

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-02-06 13:31

Message:
As for the -DUNICODE, I have thought about it in the past and I have
decided not to do it. You might want to use single copy of headers with
separate binaries for both wchar_t and char versions of the library. The
REENTRANT define does not leak into the user space, its situation is
slightly different.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-02-06 13:27

Message:
Hmm. I think that what needs changing are the bodies of toupper_func and
tolower_func, removing the inner #ifdef. I have committed the change in
revision 1521. Please try to compile it now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3174236&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3174236 ] Compilation of liblog4cplus 1.0.5 (HEAD) failed on Solaris 8

[SourceForge.net <no...@so...>]

Bugs item #3174236, was opened at 2011-02-06 07:25
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3174236&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: Pending
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Mikael Tintinger (mtintinger)
Assigned to: Václav Zeman (wilx)
Summary: Compilation of liblog4cplus 1.0.5 (HEAD) failed on Solaris 8

Initial Comment:
libtool: compile:  CC -DHAVE_CONFIG_H -DINSIDE_LOG4CPLUS -I../include -I../include -DNDEBUG -DUNICODE -D_REENTRANT -g +w -library=stlport4 -library=Crun -D_REENTRANT -c stringhelper.cxx  -KPIC -DPIC -o .libs/stringhelper.o
"stringhelper.cxx", line 360: Error: towupper is not a member of file level.
"stringhelper.cxx", line 378: Error: towlower is not a member of file level.

To build the library I have to launch ./configure CFLAGS=-DUNICODE CPPFLAGS=-DUNICODE
and include <wchar.h> for towupper and towlower functions in stringhelper.cxx.

Is it possible to make UNICODE an option as it is for REENTRANT (enable-threads) ?


----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-03 22:33

Message:
Is this fixed for you in the 1.1.0 series?

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-02-06 13:31

Message:
As for the -DUNICODE, I have thought about it in the past and I have
decided not to do it. You might want to use single copy of headers with
separate binaries for both wchar_t and char versions of the library. The
REENTRANT define does not leak into the user space, its situation is
slightly different.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-02-06 13:27

Message:
Hmm. I think that what needs changing are the bodies of toupper_func and
tolower_func, removing the inner #ifdef. I have committed the change in
revision 1521. Please try to compile it now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3174236&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Settings changed) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&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: Closed
Resolution: Fixed
Priority: 6
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

Comment By: gorpknalp (gorpknalp)
Date: 2012-09-03 16:16

Message:
Yes, that new version solves the problem on the different Linux distros I'm
trying it on.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-03 10:23

Message:
I have committed the patch to trunk.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-03 07:57

Message:
Good detective work. I have been able to reproduce the problem and I think
that the additional patch (attached) does fix the whole issue. Though I
will retest on few more systems than Cygwin later today to make sure.
Please test it as well.

----------------------------------------------------------------------

Comment By: gorpknalp (gorpknalp)
Date: 2012-09-03 03:34

Message:
I lost my previous comment because fucking sourceforge logged me out while
I was writing it, so I'm sorry if this one is not very clear.

Please note that I can reproduce that bug on Ubuntu 12.04 too.

This patch does not fix the bug. However after some debugging session I
think I figured out the source:

http://linux.die.net/man/3/pthread_getspecific :
"Both pthread_getspecific() and pthread_setspecific() may be called from a
thread-specific data destructor function. A call to pthread_getspecific()
for the thread-specific data key being destroyed shall return the value
NULL"

This is consistent with what I'm seeing while debugging, which is:
- arg has the correct memory address
- tls_storage_key has the correct memory address
- tls_storage_key points to the value
- pthread_getspecific() returns 0 when given the correct tls_storage_key as
argument

So I think the second predicate of the assert() is not correct.

But I was wondering why it does not seem to happen often so I tried to dig
a bit in the code, and my best guess is that for some reason, most people
will end up with the first version of alloc_ptd() with the "special hack"
which makes the first predicate of the assert() return true. Moreover,
threadCleanup() doesn't fail because "delete ptd;" is deleting a null
pointer.

There's a strange line in ptd_cleanup_func(), "(void) arg;" does not seem
to do anything to me and I really wonder what it's doing there. Also, I
noticed that in threadCleanup() the last line is a call to
"internal::set_ptd (0);" and after that ptd_cleanup_func() will call
"thread::impl::tls_set_value (internal::tls_storage_key, 0));" so it seems
that the value of the key is set to 0 twice.

All of this in order to say that the thread cleanup code probably needs a
bit of cleanup too :)

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:33

Message:
This looks similar to the bug reported here:
https://sourceforge.net/tracker/?func=detail&aid=3467112&group_id=40830&atid=429075

I will apply the following change (later today, also attached). Please test
if it fixes your crash.

=== modified file 'src/global-init.cxx'
--- src/global-init.cxx	2012-08-29 18:59:41 +0000
+++ src/global-init.cxx	2012-08-31 12:16:36 +0000
@@ -293,7 +293,7 @@
     // Either it is a dummy value or it should be the per thread data
     // pointer we get from internal::get_ptd().
     assert (arg == reinterpret_cast<void *>(1)
-        || arg == internal::get_ptd ());
+        || arg == internal::get_ptd (false));
     (void)arg;
 
     threadCleanup ();


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:06

Message:
Never mind, I have missed that you have attached files to this report.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:05

Message:
Thank you for the bug report. Is it easily reproducible? I have had
something similar reported before this one but I were not able to reproduce
it myself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Comment added) made by gorpknalp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&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: Fixed
Priority: 6
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

>Comment By: gorpknalp (gorpknalp)
Date: 2012-09-03 16:16

Message:
Yes, that new version solves the problem on the different Linux distros I'm
trying it on.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-03 10:23

Message:
I have committed the patch to trunk.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-03 07:57

Message:
Good detective work. I have been able to reproduce the problem and I think
that the additional patch (attached) does fix the whole issue. Though I
will retest on few more systems than Cygwin later today to make sure.
Please test it as well.

----------------------------------------------------------------------

Comment By: gorpknalp (gorpknalp)
Date: 2012-09-03 03:34

Message:
I lost my previous comment because fucking sourceforge logged me out while
I was writing it, so I'm sorry if this one is not very clear.

Please note that I can reproduce that bug on Ubuntu 12.04 too.

This patch does not fix the bug. However after some debugging session I
think I figured out the source:

http://linux.die.net/man/3/pthread_getspecific :
"Both pthread_getspecific() and pthread_setspecific() may be called from a
thread-specific data destructor function. A call to pthread_getspecific()
for the thread-specific data key being destroyed shall return the value
NULL"

This is consistent with what I'm seeing while debugging, which is:
- arg has the correct memory address
- tls_storage_key has the correct memory address
- tls_storage_key points to the value
- pthread_getspecific() returns 0 when given the correct tls_storage_key as
argument

So I think the second predicate of the assert() is not correct.

But I was wondering why it does not seem to happen often so I tried to dig
a bit in the code, and my best guess is that for some reason, most people
will end up with the first version of alloc_ptd() with the "special hack"
which makes the first predicate of the assert() return true. Moreover,
threadCleanup() doesn't fail because "delete ptd;" is deleting a null
pointer.

There's a strange line in ptd_cleanup_func(), "(void) arg;" does not seem
to do anything to me and I really wonder what it's doing there. Also, I
noticed that in threadCleanup() the last line is a call to
"internal::set_ptd (0);" and after that ptd_cleanup_func() will call
"thread::impl::tls_set_value (internal::tls_storage_key, 0));" so it seems
that the value of the key is set to 0 twice.

All of this in order to say that the thread cleanup code probably needs a
bit of cleanup too :)

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:33

Message:
This looks similar to the bug reported here:
https://sourceforge.net/tracker/?func=detail&aid=3467112&group_id=40830&atid=429075

I will apply the following change (later today, also attached). Please test
if it fixes your crash.

=== modified file 'src/global-init.cxx'
--- src/global-init.cxx	2012-08-29 18:59:41 +0000
+++ src/global-init.cxx	2012-08-31 12:16:36 +0000
@@ -293,7 +293,7 @@
     // Either it is a dummy value or it should be the per thread data
     // pointer we get from internal::get_ptd().
     assert (arg == reinterpret_cast<void *>(1)
-        || arg == internal::get_ptd ());
+        || arg == internal::get_ptd (false));
     (void)arg;
 
     threadCleanup ();


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:06

Message:
Never mind, I have missed that you have attached files to this report.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:05

Message:
Thank you for the bug report. Is it easily reproducible? I have had
something similar reported before this one but I were not able to reproduce
it myself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&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: Fixed
Priority: 6
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-03 10:23

Message:
I have committed the patch to trunk.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-09-03 07:57

Message:
Good detective work. I have been able to reproduce the problem and I think
that the additional patch (attached) does fix the whole issue. Though I
will retest on few more systems than Cygwin later today to make sure.
Please test it as well.

----------------------------------------------------------------------

Comment By: gorpknalp (gorpknalp)
Date: 2012-09-03 03:34

Message:
I lost my previous comment because fucking sourceforge logged me out while
I was writing it, so I'm sorry if this one is not very clear.

Please note that I can reproduce that bug on Ubuntu 12.04 too.

This patch does not fix the bug. However after some debugging session I
think I figured out the source:

http://linux.die.net/man/3/pthread_getspecific :
"Both pthread_getspecific() and pthread_setspecific() may be called from a
thread-specific data destructor function. A call to pthread_getspecific()
for the thread-specific data key being destroyed shall return the value
NULL"

This is consistent with what I'm seeing while debugging, which is:
- arg has the correct memory address
- tls_storage_key has the correct memory address
- tls_storage_key points to the value
- pthread_getspecific() returns 0 when given the correct tls_storage_key as
argument

So I think the second predicate of the assert() is not correct.

But I was wondering why it does not seem to happen often so I tried to dig
a bit in the code, and my best guess is that for some reason, most people
will end up with the first version of alloc_ptd() with the "special hack"
which makes the first predicate of the assert() return true. Moreover,
threadCleanup() doesn't fail because "delete ptd;" is deleting a null
pointer.

There's a strange line in ptd_cleanup_func(), "(void) arg;" does not seem
to do anything to me and I really wonder what it's doing there. Also, I
noticed that in threadCleanup() the last line is a call to
"internal::set_ptd (0);" and after that ptd_cleanup_func() will call
"thread::impl::tls_set_value (internal::tls_storage_key, 0));" so it seems
that the value of the key is set to 0 twice.

All of this in order to say that the thread cleanup code probably needs a
bit of cleanup too :)

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:33

Message:
This looks similar to the bug reported here:
https://sourceforge.net/tracker/?func=detail&aid=3467112&group_id=40830&atid=429075

I will apply the following change (later today, also attached). Please test
if it fixes your crash.

=== modified file 'src/global-init.cxx'
--- src/global-init.cxx	2012-08-29 18:59:41 +0000
+++ src/global-init.cxx	2012-08-31 12:16:36 +0000
@@ -293,7 +293,7 @@
     // Either it is a dummy value or it should be the per thread data
     // pointer we get from internal::get_ptd().
     assert (arg == reinterpret_cast<void *>(1)
-        || arg == internal::get_ptd ());
+        || arg == internal::get_ptd (false));
     (void)arg;
 
     threadCleanup ();


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:06

Message:
Never mind, I have missed that you have attached files to this report.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:05

Message:
Thank you for the bug report. Is it easily reproducible? I have had
something similar reported before this one but I were not able to reproduce
it myself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830