Revised boost/config/compiler/gcc.hpp causes linker errors for Cygwin WIN32 apps

[cvclarkeiii@…]

A revision to boost/config/compiler/gcc.hpp makes the assumption that because Cygwin does not define a WIN32 macro, a WIN32 macro will never be defined when compiling applications for Cygwin. Win32 applications are supported under Cygwin, and the use of some third party libs (i.e. Agilent I/O Libraries) requires that a WIN32 macro be defined. This problem causes linker errors similar to the error below:

scons: done reading SConscript files. scons: Building targets ... g++ -o test_serialization.o -c -g -Wall -ansi -mwin32 -mthreads -I/c/dvlp/boost_1_44_0 test_serialization.cpp g++ -o test_serialization.exe test_serialization.o -L/c/dvlp/boost_1_44_0/stage/lib -lboost_serialization -lboost_date_time -lboost_system Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBALN_116guid_initializerI7DerivedEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBALN_116guid_initializerI7DerivedEEE20get_mutable_instanceEv: symbol not found collect2: ld returned 1 exit status scons: * [test_serialization.exe] Error 1 scons: building terminated because of errors.

A patch is attached that fixes this problem

[cvclarke@…]

Patch for boost/config/compiler/gcc.hpp

[cvclarkeiii@…]

zip file containing a program that demonstrates the problem for Cygwin

[John Maddock]

(In [65530]) Fix for cygwin symbol visibility - sometimes _WIN32 may be defined even on cygwin. Fixes #4670.

[setosha@…]

I got same error on mingw from qt 4.7.0. Your fix

boost 1.43 works fine...

boost 1.44 with staticly linked boost_serialization

Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_15binary_iarchiveEEEE12get_instanceEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_15binary_iarchiveEEEE12is_destroyedEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_15binary_iarchiveEEEE18get_const_instanceEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_15binary_iarchiveEEEE20get_mutable_instanceEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_15binary_oarchiveEEEE12get_instanceEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_15binary_oarchiveEEEE12is_destroyedEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_15binary_oarchiveEEEE18get_const_instanceEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_15binary_oarchiveEEEE20get_mutable_instanceEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_21naked_binary_iarchiveEEEE12get_instanceEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_21naked_binary_iarchiveEEEE12is_destroyedEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_21naked_binary_iarchiveEEEE18get_const_instanceEv: symbol not found
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_21naked_binary_iarchiveEEEE20get_mutable_instanceEv: symbol not found
collect2: ld returned 1 exit status

[John Maddock]

I've tracked this down to a bug in the serialization library, so I'm reassigning the issue.

Robert, here's the problem: When basic_iarchive.cpp is compiled the class "extened_type_info" is declared dllimport, as a result the linker is looking for the member functions of that class in a dll... except they're not present in an external dll, they're present in *this* dll and marked dllexport.

Here's what gcc is doing here: dllexport just marks the symbol as visible, but doesn't change it's mangled name. dllimport changes the mangled name instructs the linker to create stub code for that symbol with the imp prefix that looks for the unmangled name in an external dll. Hense you can't mix import and export of the same symbol in the same dll. The same code compiles with msvc and gcc on linux due to chance really - they just happen to treat import and export as largely the same thing.

In other words in the serialization sources - since each .cpp file appears in only one library, there should be just 2 source macros, lets say BOOST_SERIALIZATION_SOURCE and BOOST_WSERIALIZATION_SOURCE that control what gets built with import or export. BOOST_ARCHIVE_SOURCE can presumably be replaced by BOOST_SERIALIZATION_SOURCE and associated macros since all the archive sources are really just part of the narrow character serialization lib, and not a separate lib in their own right? Further these macros should be defined *before any serialization or archive headers are included*, otherwise you run the risk of inconsistent settings again.

HTH, John.

[Robert Ramey]

Thanks for the explanation. I realized that this was a problem when my msvc linker warned of the same symbols being exported and imported in the same group of modules. I hadn't figured out to resolve this so your suggestions are helpful. Unfortunately, I'm currently bogged down on some other stuff so I can't address it immediately.

Robert Ramey

[Robert Ramey]

I've fixed this and checked the update into the trunk