Modify

Opened 7 years ago

Closed 7 years ago

#4670 closed Bugs (fixed)

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

Reported by: cvclarkeiii@… Owned by: Robert 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 (2)

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

Download all attachments as: .zip

Change History (9)

Changed 7 years ago by cvclarke@…

Attachment: boost-config.patch added

Patch for boost/config/compiler/gcc.hpp

Changed 7 years ago by cvclarkeiii@…

Attachment: serialization_problem.zip added

zip file containing a program that demonstrates the problem for Cygwin

comment:1 Changed 7 years ago by John Maddock

Resolution: fixed
Status: newclosed

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

comment:2 Changed 7 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 7 years ago by Anton Sergunov <setosha@…>

Cc: setosha@… added

comment:4 Changed 7 years ago by John Maddock

Component: configserialization
Resolution: fixed
Status: closedreopened

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 7 years ago by John Maddock

Owner: changed from John Maddock to Robert Ramey
Status: reopenednew

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

comment:7 Changed 7 years ago by Robert Ramey

Resolution: fixed
Status: newclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Robert Ramey.
The resolution will be deleted.

Add Comment


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

 
Note: See TracTickets for help on using tickets.