From: Konstantin L. <Kon...@ma...> - 2007-08-17 08:12:18
|
Hello, Scott! You wrote to <log...@li...> on Thu, 16 Aug 2007 23:28:11 -0400: SC> A long time back, pre-2004 certainly, we realized that log4cpp was SC> extremely broken under even rudimentary threaded conditions. I traced SC> this problem to two main sources: SC> - use of the non-threadsafe localtime function Fixed in my local copy. SC> - a broken autotools script that failed to set the proper flags on SC> Solaris and other platforms Waiting patch that fix this issue from Russ Allbery. SC> (To my knowledge, the NDC class was always threadsafe (it uses SC> thread-local-storage), in contrast to some recent comments here. I SC> can't explain that, but I think the concerns there are wrong.) You are right :) My previuos investigation was wrong. I have reviewed one more time NDC and PThread code and now realize that everything is OK with it. With best regards, Konstantin Litvinenko. |
From: Scott C. <can...@os...> - 2007-08-17 16:35:57
|
> SC> - a broken autotools script that failed to set the proper flags on > SC> Solaris and other platforms > > Waiting patch that fix this issue from Russ Allbery. If you don't have it yet, I can provide my copy of the configure script, or you can get it from inside the old package I posted: http://shibboleth.internet2.edu/downloads/log4cpp-0.3.5rc1.tar.gz There are various changes to fix threading but also to correct C++ build issues on platforms where using gcc as a link front-end for C++ is not possible (i.e. everywhere but Linux). If there's a specific change that is controversial, I can go back and determine what the change was for, I just don't have a list offhand as it was many years ago. -- Scott |
From: Konstantin L. <1da...@ma...> - 2007-08-19 11:11:43
|
Hello, Scott! You wrote to <log...@li...> on Fri, 17 Aug 2007 12:35:47 -0400: SC> There are various changes to fix threading but also to correct C++ SC> build issues on platforms where using gcc as a link front-end for C++ SC> is not possible (i.e. everywhere but Linux). SC> If there's a specific change that is controversial, I can go back and SC> determine what the change was for, I just don't have a list offhand as SC> it was many years ago. I have commited localtime_r fix and pthread support. I check build on Fedora 7. Please check on non Linux to be sure that everything is OK. I am as blind with all this autotools, configure and others so mistakes are assumed. With best regards, Konstantin Litvinenko. E-mail: Kon...@ma... |
From: Scott C. <can...@os...> - 2007-08-19 23:00:00
|
> I have commited localtime_r fix and pthread support. I check build on > Fedora 7. Please check on non Linux to be sure that everything is OK. I am > as blind with all this autotools, configure and others so mistakes are > assumed. Well, there are a couple of issues: Not all of my changes are there, and all of them were done for a reason. For example, the language isn't correctly set to C or C++ in the right places to ensure the tests run correctly. The existing script uses C++ prematurely, which fails on most platforms, rather that starting with C and then switching for the C++ tests. Lastly, and more importantly, I don't believe my use of the thread macros is compatible with the existing macros that are still being called: BB_CHECK_OMNITHREADS BB_CHECK_PTHREADS The second one probably overlaps and the first one would probably break. I commented them out in my version because I don't know what OMNITHREADS is and my code can't allow it anyway, so I didn't need to support it. If you're trying to support that and pthreads properly, there's more work required, and some testing that I couldn't do. If not, you just comment them out and it requires pthreads be used. The current script with part of my changes is already blocking use of any option other than pthreads, in fact, which is not necessarily what you want. For reference, the diff I ran is below with the changes that matter left in. -- Scott # diff configure.in ~/src/log4cpp-0.3.5rc1/configure.in 49a50,54 > if test "$GCC" = "yes" ; then > CFLAGS="$GCC_CFLAGS" > CXXFLAGS="$GCC_CXXFLAGS" > fi > 51c56 < AC_LANG(C++) --- > AC_LANG(C) 61d65 < AC_CXX_HAVE_SSTREAM 89a89,92 > AC_LANG(C++) > > AC_CXX_HAVE_SSTREAM > 103,104c106,107 < BB_CHECK_OMNITHREADS < BB_CHECK_PTHREADS --- > #BB_CHECK_OMNITHREADS > #BB_CHECK_PTHREADS |
From: Konstantin L. <Kon...@ma...> - 2007-08-20 10:07:13
|
Hello, Scott! You wrote to <log...@li...> on Sun, 19 Aug 2007 18:59:52 -0400: SC> Well, there are a couple of issues: SC> Not all of my changes are there, and all of them were done for a SC> reason. Yes and sorry. I was not sure about changing language from C++ to C is correct. Now I understend why it is needed. SC> For example, the language isn't correctly set to C or C++ in the right [Sorry, skipped] SC> For reference, the diff I ran is below with the changes that matter SC> left in. I think I have fixed all this. Please, check again. With best regards, Konstantin Litvinenko. |