Boost C++ Libraries: Ticket #4670: Revised boost/config/compiler/gcc.hpp causes linker errors for Cygwin WIN32 apps

attachment set

cvclarke@… — Tue, 21 Sep 2010 22:06:39 GMT

attachment → boost-config.patch

Patch for boost/config/compiler/gcc.hpp

attachment set

cvclarkeiii@… — Tue, 21 Sep 2010 22:08:17 GMT

attachment → serialization_problem.zip

zip file containing a program that demonstrates the problem for Cygwin

status changed; resolution set

John Maddock — Wed, 22 Sep 2010 08:24:12 GMT

status new → closed
resolution → fixed

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

setosha@… — Wed, 29 Sep 2010 18:16:05 GMT

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

cc set

Wed, 29 Sep 2010 18:32:31 GMT

cc setosha@… added

status, component changed; resolution deleted

John Maddock — Fri, 08 Oct 2010 09:24:02 GMT

status closed → reopened
resolution fixed
component config → serialization

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.

owner, status changed

John Maddock — Fri, 08 Oct 2010 09:24:36 GMT

owner changed from John Maddock to Robert Ramey
status reopened → new

Robert Ramey — Fri, 08 Oct 2010 16:18:15 GMT

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

status changed; resolution set

Robert Ramey — Wed, 20 Oct 2010 16:10:50 GMT

status new → closed
resolution → fixed

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