6

On upgrading to boost 1.60.0 some applications are failing to link with boost log when built with MinGw 4.9.2 on Windows 7.

I get the following linker errors:

undefined reference to `_imp___ZN5boost3log9v2_mt_nt67trivial6logger3getEv'
undefined reference to `_imp___ZN5boost3log9v2_mt_nt63aux15stream_providerIcE17allocate_compoundERNS1_6recordE'
undefined reference to `_imp___ZN5boost3log9v2_mt_nt63aux25unhandled_exception_countEv'
undefined reference to `_imp___ZN5boost3log9v2_mt_nt611record_view11public_data7destroyEPKS3_'
bad reloc address 0x1 in section `.text$_ZNK5boost4asio5error6detail13misc_category4nameEv[__ZNK5boost4asio5error6detail13misc_category4nameEv]'

Note: BOOST_LOG_DYN_LINK is defined: 

g++ -c -pipe -fno-keep-inline-dllexport -Wall -Wextra -Wpedantic -Ofast -std=c++1y -frtti -fexceptions -mthreads -DUNICODE -DLOGGING_ENABLED -DNTDDI_VERSION=NTDDI_WIN7 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 -DBOOST_THREAD_USE_LIB=1 -DBOOST_LOG_DYN_LINK=1

The boost 1.60.0 build log file shows that both boost log and boost log_setup built without any errors or warnings, including some of the files that it's failing to link with e.g.:

gcc.compile.c++ bin.v2\libs\log\build\gcc-mingw-4.9.2\release\threading-multi\trivial.o
gcc.compile.c++ bin.v2\libs\log\build\gcc-mingw-4.9.2\release\threading-multi\unhandled_exception_count.o

The applications link OK using boost 1.59.0 with MinGw 4.9.2 on Windows 7 and also link OK using boost 1.60.0 with gcc 5.1.1 on Fedora 23.

boost asio hasn't changed since boost 1.58.0. So what's changed in boost log between boost 1.59.0 and boost 1.60.0 to cause MinGw linking to fail on Windows?

kenba
  • 4,303
  • 1
  • 23
  • 40

1 Answers1

9

Boost.Log was probably built with different options than your application, so it has a differently named version namespace. Have a look at the exported symbols with Dependency Walker and see the description. I suspect, the difference will be in the OS API component of the namespace, as the setup of the target Windows version has changed in 1.60. You're building your application for Windows 7 while Boost.Log is most likely built for Windows XP.

When you identify the difference, you have to correct Boost building options and rebuild Boost. E.g. to set target Windows version to 7 define BOOST_USE_WINAPI_VERSION to 0x0601. If you don't want to change Windows version Boost is targeted for, you can define BOOST_USE_WINAPI_VERSION to 0x0501 while building your application, indicating that you want Boost to keep targeting XP even though your application is targeting 7.

Andrey Semashev
  • 10,046
  • 1
  • 17
  • 27
  • Thank you @andrey, 'Dependency Walker` showed the version as `_ZN5boost3log9v2_mt_nt54core3getEv` and setting `BOOST_USE_WINAPI_VERSION=0x0501` fixed the build. And thank you for such creating such a great library in the first place. I would like to set `BOOST_USE_WINAPI_VERSION=0x601` whilst building boost but how should do it? I could set it in `boost/detail/winapi/config.hpp' but I'd prefer not to edit your files. Can I pass the macro to b2 whilst [building boost](http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html)? – kenba Dec 22 '15 at 11:27
  • You can do this the same way you specify other [config macros](http://www.boost.org/doc/libs/1_60_0/libs/log/doc/html/log/installation/config.html) - by adding `define=BOOST_USE_WINAPI_VERSION=0x0601` to b2 command line. – Andrey Semashev Dec 23 '15 at 09:55
  • I tried adding `define=BOOST_USE_WINAPI_VERSION=0x0601` and a few other combinations of `BOOST_USE_WINAPI_VERSION` and `_WIN32_WINNT` as well but none worked for me. It failed compiling `chrono` because `GetTickCount64` wasn't declared. From your comments in `boost/detail/winapi/config.hpp` I can see that the problem is that I'm using `MinGw` (from QtCreator) and not `MinGw64`: only `GetTickCount` is defined in `winbase.h` So I'm stuck with setting `BOOST_USE_WINAPI_VERSION=0x0501` until `MinGw` is updated... Thanks for your help. – kenba Dec 23 '15 at 16:09