Modify

Ticket #4670 (closed Bugs: fixed)

Opened 4 years ago

Last modified 4 years ago

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

Reported by: cvclarkeiii@… Owned by: ramey
Milestone: To Be Determined Component: serialization
Version: Boost 1.44.0 Severity: Problem
Keywords: Cc: setosha@…

Description

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

Attachments

boost-config.patch Download (787 bytes) - added by cvclarke@… 4 years ago.
Patch for boost/config/compiler/gcc.hpp
serialization_problem.zip Download (5.1 KB) - added by cvclarkeiii@… 4 years ago.
zip file containing a program that demonstrates the problem for Cygwin

Change History

Changed 4 years ago by cvclarke@…

Patch for boost/config/compiler/gcc.hpp

Changed 4 years ago by cvclarkeiii@…

zip file containing a program that demonstrates the problem for Cygwin

comment:1 Changed 4 years ago by johnmaddock

  • Status changed from new to closed
  • Resolution set to fixed

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

comment:2 Changed 4 years ago by 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

comment:3 Changed 4 years ago by Anton Sergunov <setosha@…>

  • Cc setosha@… added

comment:4 Changed 4 years ago by johnmaddock

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Component changed from config to 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.

comment:5 Changed 4 years ago by johnmaddock

  • Owner changed from johnmaddock to ramey
  • Status changed from reopened to new

comment:6 Changed 4 years ago by 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

comment:7 Changed 4 years ago by ramey

  • Status changed from new to closed
  • Resolution set to fixed

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

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.