On Mar 31, 2008, at 8:39 AM, Jostein Tveit wrote:
./src/test/cpp/logunit.cpp is missing "#include <locale.h>" to compile on Solaris 8 with Sun Studio 11. I have only tested RC6, but I think RC7 has the same issue.
I'm sure it would. The issue is that the definition of setlocale() is apparently made available by #include <stdlib.h> with the other compilers tested, but is documented to be defined in <locale.h>.
I also got 2 errors in the unit tests with Sun Studio 11 64bit compilation on Solaris 8. I will dig into the errors tomorrow, but at the moment I will not recommend RC6 or RC7 to be published.
Not sure if you are saying you got two compilation errors on the unit tests or after you compiled the unit tests, two unit tests failed. In either case, it would be great if you could provide the either the compilation errors or the test failure reports.
Does it look like LOGCXX-244? In that particular case, the unit tests fail on MinGW 3.4.5 for an unknown reason perhaps a problem in the implementation of the standard C++ library on that platform. In that particular case, I thought that it was reasonable to note that test failure for that platform but not hold up a release.
I have seen timebaserollingtest fail intermittently which I've logged as LOGCXX-260. The test predicts the file names of the per-second rollover files and an unexpected lag will result in a mismatch between the predicted file names and the actual file names. The resolution would be to rework the test to examine the file names in the output directory and match those to the appropriate files for comparison. Typically, the problem will go away the next time you run the tests.
If the problem seems platform specific or a problem with how the test is written, I'd be in favor with proceeding with log4cxx 0.10.0 RC7 and fix the problems in log4cxx 0.10.1. Obviously, we have been anything but "release often" (0.9.7 is almost 4 years old), but hopefully after we get the first release under our belt, subsequent releases would follow. In the Apache ethos, end user developers are supposed to be working with frequent releases, not release candidates or directly with the SVN. For many years, we have been in the situation of having a buggy release that does not satisfy the current release criteria for an ASF release but haven't had a release to which to direct users. I think publishing RC7 as is overwhelmingly preferable to leaving log4cxx 0.9.7 as the most recent release.
Please provide details as soon as possible, but I would still encourage testing and am not ready to scuttle RC7.
