Fail to build using mingw 4.9.1 about log4cplus HOT 12 CLOSED

Are you saying that the recent change to use InterlockedExchangeAdd does not work for you?

from log4cplus.

Correct, in my version of mingw InterlockedExchangeAdd does not exist.

from log4cplus.

@jpschewe I have just downloaded the distribution (http://netcologne.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-posix/seh/x86_64-4.9.1-release-posix-seh-rt_v3-rev3.7z) and I do see the function there. I have just done a test build with CMake and everything compiled.

Are you using a different distribution? What is your GCC? I need more specific information how to reproduce this.

from log4cplus.

I'm using mingw32 4.9.1 that is distributed with Qt 5.4.1. That distribution can be found here:
http://download.qt.io/archive/qt/5.4/5.4.1/qt-opensource-windows-x86-mingw491_opengl-5.4.1.exe

from log4cplus.

@jpschewe I cannot reproduce it with that Qt distributed MinGW either. How do you build it?

from log4cplus.

I have a windows system with a basic mingw32 install, no tool chain, just bash so that I can execute scripts.
I have Qt 5.4.1 installed in q:\5.4.1
I have git installed in c:\packages\Git

I open a basic mingw32 shell from the start menu.

$ uname -a
MINGW32_NT-6.1 JSCHEWE-WIN7 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys

I then set some variables based on which system I'm on:

windows_qmake_bin=/Qt/Qt5.4.1/5.4/mingw491_32/bin
windows_mingw_bin=/Qt/Qt5.4.1/Tools/mingw491_32/bin
qt_drive=q
PATH=${PATH}:/c/packages/Git/bin
PATH=/${qt_drive}/${windows_qmake_bin}:${PATH}
PATH=/${qt_drive}/${windows_mingw_bin}:${PATH}

I then build, setting the unicode build flags allows log4cplus to be compatible with Qt, without it I get errors about tsopen not getting the right arguments when building the Qt application that links to log4cplus.

tar -xzf log4cplus-1.2.0-rc6.tar.gz
cd log4cplus-1.2.0-rc6
CXXFLAGS="-DUNICODE -D_UNICODE" ./configure \
  --prefix="../install/debug" \
  --disable-static 
make

Here is the error, wrapping is bad as it's copied from a windows mingw shell.

/bin/sh ./libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H   -I./include
-I./include -DNDEBUG -DINSIDE_LOG4CPLUS -D_GNU_SOURCE=1 -U__STRICT_ANSI__ -DWIN3
2 -D_WIN32 -DMINGW_HAS_SECURE_API=1 -D_REENTRANT  -g -O2 -Wall -fdiagnostics-sho
w-caret -ftrack-macro-expansion -fdiagnostics-color=auto -Wextra -pedantic -Wstr
ict-aliasing -Wstrict-overflow -Woverloaded-virtual -Wc++0x-compat -Wc++11-compa
t -Wundef -Wshadow -Wformat -Wsuggest-attribute=format -Wsuggest-attribute=noret
urn -Wno-variadic-macros -fvisibility=hidden  -MT src/liblog4cplus_la-socket-win
32.lo -MD -MP -MF src/.deps/liblog4cplus_la-socket-win32.Tpo -c -o src/liblog4cp
lus_la-socket-win32.lo `test -f 'src/socket-win32.cxx' || echo './'`src/socket-w
in32.cxx
libtool: compile:  g++ -DHAVE_CONFIG_H -I./include -I./include -DNDEBUG -DINSIDE
_LOG4CPLUS -D_GNU_SOURCE=1 -U__STRICT_ANSI__ -DWIN32 -D_WIN32 -DMINGW_HAS_SECURE
_API=1 -D_REENTRANT -g -O2 -Wall -fdiagnostics-show-caret -ftrack-macro-expansio
n -fdiagnostics-color=auto -Wextra -pedantic -Wstrict-aliasing -Wstrict-overflow
 -Woverloaded-virtual -Wc++0x-compat -Wc++11-compat -Wundef -Wshadow -Wformat -W
suggest-attribute=format -Wsuggest-attribute=noreturn -Wno-variadic-macros -fvis
ibility=hidden -MT src/liblog4cplus_la-socket-win32.lo -MD -MP -MF src/.deps/lib
log4cplus_la-socket-win32.Tpo -c src/socket-win32.cxx  -DDLL_EXPORT -DPIC -o src
/.libs/liblog4cplus_la-socket-win32.o
src/socket-win32.cxx: In function 'void {anonymous}::init_winsock_worker()':
src/socket-win32.cxx:92:59: error: 'InterlockedAdd' was not declared in this sco
pe
             LONG state = InterlockedAdd (&winsock_state, 0);
                                                           ^
make[3]: *** [src/liblog4cplus_la-socket-win32.lo] Error 1
make[3]: Leaving directory `/q/log4cxx-test/log4cxx/source/log4cplus-1.2.0-rc6'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/q/log4cxx-test/log4cxx/source/log4cplus-1.2.0-rc6'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/q/log4cxx-test/log4cxx/source/log4cplus-1.2.0-rc6'
make: *** [install/debug/include/log4cplus/logger.h] Error 2

from log4cplus.

First, I do not support MSYS/MinGW. I have not tried for a long time but few years back it did not work well or at all. Instead, on MSYS/MinGW, please use CMake build system to build log4cplus.

Second, as for the error above, this should be fixed in the 1.2.0 release by 3636758.

from log4cplus.

Can I use CMake to build on Mac and Linux as well? I prefer not to need to use a different build system on each of my targets. That's why I was using configure rather than CMake.

from log4cplus.

Well, it works at least on Linux, I have tested that in the past. I do not know about Mac OS X, I have no access to that, but I expect it to work.

from log4cplus.

Given that my build is working in in this mingw environement now. Is there something I should watch out for? The library builds fine with this change and my programs behave as expected. What issues did you have with MSYS/MinGW before?

As far as autotools vs. CMake, are you planning on supporting both build environments forever or do you expect to drop one at some point?

from log4cplus.

Given that my build is working in in this mingw environement now. Is there something I should watch out for? The library builds fine with this change and my programs behave as expected. What issues did you have with MSYS/MinGW before?

If it compiles and tests are actually executable, there should be no problem. The problem was, and still is IIRC, that the MSYS build configures and generates defines.hxx which is not used at all. From config.hxx:

#if defined (_WIN32)
#  include <log4cplus/config/win32.h>
#elif (defined(__MWERKS__) && defined(__MACOS__))
#  include <log4cplus/config/macosx.h>
#else
#  include <log4cplus/config/defines.hxx>
#endif

The configuration on Windows is based only on compile time detectable macros and versions, and bunch of fixed Windows specific #defines.

As far as autotools vs. CMake, are you planning on supporting both build environments forever or do you expect to drop one at some point?

I am not going to drop either of the 3, the third being Visual Studio project files, currently supported build methods "ever". They each have their users.

from log4cplus.

I see that I have defines.hxx, but everything builds fine and executes fine. Given this, I'm likely to stick with the autotools build rather than switching to cmake.

Thank you very much for your quick responses.

from log4cplus.