Proper way of building

[Peter R]

What is the proper way to build log4cpp?
Recently I tried to build log4cpp (1.1.3) on 3 different operating systems using different methods and achieved the following results:

---

SUSE Linux Enterprise 11 SP1 x64 using configure, gcc/g++ 4.3:

"configure" ends with:

...
creating include/log4cpp/config.h - prefix LOG4CPP for include/config.h defines
dirname: extra operand `/bin'
Try `dirname --help' for more information.
/

and

"make > /dev/null" ends with:

../../src/BufferingAppender.cpp: In member function ‘virtual void log4cpp::BufferingAppender::_append(const log4cpp::LoggingEvent&)’:
../../src/BufferingAppender.cpp:24: warning: suggest explicit braces to avoid ambiguous ‘else’
../../tests/Clock.cpp:21:1: warning: use of C99 long long integer constant

And a static library "liblog4cpp.a" along with a dynamic library "liblog4cpp.so.5.0.6" is created, what I find almost OK, considering the warning/error of "configure".

---

SUSE Linux Enterprise 11 SP1 x64 using CMakeLists.txt (cmake), gcc/g++ 4.3:

"cmake" and "make > /dev/null" (after supplying an empty "include/log4cpp/config.h") both end without any (significant) warnings/errors, but only the static library "liblog4cpp.a" is created.

---

SUSE Linux Enterprise 12 SP2 x64 using configure, gcc/g++ 4.8.5:

"configure" ends without the error/warning issued on SLE 11.
"make > /dev/null" ends with:

../../src/BufferingAppender.cpp: In member function 'virtual void log4cpp::BufferingAppender::_append(const log4cpp::LoggingEvent&)':
../../src/BufferingAppender.cpp:24:10: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
       if (queue_.size() == max_size_)
          ^
In file included from ../../tests/Clock.cpp:17:0:
../../tests/Clock.cpp:21:46: warning: use of C++0x long long integer constant [-Wlong-long]
     const usec_t UsecPerSec = INT64_CONSTANT(1000000);
                                              ^
../../tests/Clock.hh:20:34: note: in definition of macro ‘INT64_CONSTANT’
#   define INT64_CONSTANT(val)  (val##LL)

... and some irrelevant errors from Doxygen.
In this case both the static and the dynamic library are created.

---

SUSE Linux Enterprise 12 SP2 x64 using CMakeLists.txt (cmake), gcc/g++ 4.8.5:

"cmake" ends without any errors/warnings.
"make > /dev/null" ends with:

/home/letvis/Sources/log4cpp/src/FileAppender.cpp: In member function ‘virtual void log4cpp::FileAppender::close()’:
/home/letvis/Sources/log4cpp/src/FileAppender.cpp:54:13: error: ‘::close’ has not been declared
             ::close(_fd);
             ^
/home/letvis/Sources/log4cpp/src/FileAppender.cpp: In member function ‘virtual void log4cpp::FileAppender::_append(const log4cpp::LoggingEvent&)’:
/home/letvis/Sources/log4cpp/src/FileAppender.cpp:81:14: error: ‘::write’ has not been declared
         if (!::write(_fd, message.data(), message.length())) {
              ^
/home/letvis/Sources/log4cpp/src/FileAppender.cpp: In member function ‘virtual bool log4cpp::FileAppender::reopen()’:
/home/letvis/Sources/log4cpp/src/FileAppender.cpp:93:21: error: ‘::close’ has not been declared
                     ::close(_fd);
                     ^

Nothing is created.

---

Windows 7 x64 using MSVC 12 (Visual Studio 2013)

"cmake-gui" ends without errors.
Compilation of target "log4cpp" in Visual Studio ends with warnings about "open", "lseek", "write", "close", "unlink" and some others, but succeeds in creating only the static library.

---

My main question therefore is: What is the correct way to build the project?
And some more sub-questions:
Wouldn't it be smart to unify the build process to one possible way (e.g. cmake)?
Wouldn't it be smart for the build process to create both the static and the dynamic versions of the library?

Side note:
I don't mean any offense, I'm just trying to be constructive and move the project a little further, as I like the project, but not much has changed since the late 2015, when I first encountered the project. Especially not the building process.

[Alexander Perepelkin]

Hi Peter,

Thanks for this in-depth compilation.
As you noticed, autogen & configure is the most supported way. It builds libraries, although the warnings that you've seen are worth to be fixed.
cmake was just side experiment, and people around try to use it and fix it. The founders of the project insist that autogen scripts should be maintained as first priority. Cmake is good to have in working state although.
VS has different targets for dynamic/static/some other options. Have you tried them?

Alex.

[Peter R]

Hey Alex,

no, I haven't tried any other options. I have tried the "out-of-the-box" builds only. I was wondering if the build systems produce the same or different results.
But now I see there is a fork addressing this issue (no. 6 ) waiting to be merged - perhaps it will solve (at least some of) these issues I encountered. Will it be merged anytime soon? Or do you want me to try it first?

[Alexander Perepelkin]

Peter,

In VS user should choose what should be built afair.
I am aware of that merge request. Unfortunately, I am very short on time that I can devote to the project.
If you could test this request, it would make great deal.

Thanks,
Alex.