Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.0k views
in Technique[技术] by (71.8m points)

gcc - Problems Linking boost log 1_60 with MinGw on Windows 7

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.v2libsloguildgcc-mingw-4.9.2
eleasehreading-multirivial.o
gcc.compile.c++ bin.v2libsloguildgcc-mingw-4.9.2
eleasehreading-multiunhandled_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?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...