[serialization] unable to link on OS X when MACOSX_DEPLOYMENT_TARGET=10.7
Hello, I'd like to build the boost_serialization library with a compatibility setup for Mac OS X version 10.7, because I need to use it with Anaconda Python binaries, which are built for OS X 10.7. The OS X compatibility version can be set either by passing `-mmacosx-version-min=10.7` as a compile and link option or by setting environment variable MACOSX_DEPLOYMENT_TARGET=10.7. If I do so, the boost_serialization library builds without complaints, however I am not able to link it with my test program. Here are the steps I take to compile boost_serialization and the test program starting from a fresh boost 1.64.0 tree: # -------------------------------------------------------------- $ export MACOSX_DEPLOYMENT_TARGET=10.7 $ ./bootstrap.sh $ ./b2 -j4 variant=release link=shared --with-serialization stage # The stage/lib directory now contains libboost_serialization.dylib. # Use it to build a test program from tarchive.cpp: $ c++ tarchive.cpp -I. -Lstage/lib -lboost_serialization Undefined symbols for architecture x86_64: "boost::archive::basic_binary_oprimitive<boost::archive::binary_oarchive, char, std::char_traits<char> >::init()", referenced from: boost::archive::binary_oarchive_impl<boost::archive::binary_oarchive, char, std::char_traits<char> >::init(unsigned int) in tarchive-5e24a9.o "boost::archive::basic_binary_oprimitive<boost::archive::binary_oarchive, char, std::char_traits<char> >::save(std::string const&)", referenced from: void boost::archive::save_access::save_primitive<boost::archive::binary_oarchive, std::string>(boost::archive::binary_oarchive&, std::string const&) in tarchive-5e24a9.o ... # -------------------------------------------------------------- The only thing the test program (attached) does is to instantiate the boost::archive::binary_oarchive class. The procedure above works fine when MACOSX_DEPLOYMENT_TARGET is set to 10.9 or higher. Am I missing some option that would fix the failed linking when building for OS X 10.7? I suppose this could be related to object visibility options as the serialization library is compiled with "-fvisibility=hidden" and "-fvisibility-inlines-hidden" options. Thank you, Pavol
On 6/26/17 12:36 PM, Pavol Juhas via Boost-users wrote:
Hello,
I'd like to build the boost_serialization library with a compatibility setup for Mac OS X version 10.7, because I need to use it with Anaconda Python binaries, which are built for OS X 10.7. The OS X compatibility version can be set either by passing `-mmacosx-version-min=10.7` as a compile and link option or by setting environment variable MACOSX_DEPLOYMENT_TARGET=10.7.
If I do so, the boost_serialization library builds without complaints, however I am not able to link it with my test program. Here are the steps I take to compile boost_serialization and the test program starting from a fresh boost 1.64.0 tree:
# --------------------------------------------------------------
$ export MACOSX_DEPLOYMENT_TARGET=10.7 $ ./bootstrap.sh $ ./b2 -j4 variant=release link=shared --with-serialization stage
# The stage/lib directory now contains libboost_serialization.dylib. # Use it to build a test program from tarchive.cpp:
$ c++ tarchive.cpp -I. -Lstage/lib -lboost_serialization Undefined symbols for architecture x86_64: "boost::archive::basic_binary_oprimitive<boost::archive::binary_oarchive, char, std::char_traits<char> >::init()", referenced from: boost::archive::binary_oarchive_impl<boost::archive::binary_oarchive, char, std::char_traits<char> >::init(unsigned int) in tarchive-5e24a9.o "boost::archive::basic_binary_oprimitive<boost::archive::binary_oarchive, char, std::char_traits<char> >::save(std::string const&)", referenced from: void boost::archive::save_access::save_primitive<boost::archive::binary_oarchive, std::string>(boost::archive::binary_oarchive&, std::string const&) in tarchive-5e24a9.o ...
# --------------------------------------------------------------
The only thing the test program (attached) does is to instantiate the boost::archive::binary_oarchive class. The procedure above works fine when MACOSX_DEPLOYMENT_TARGET is set to 10.9 or higher.
Am I missing some option that would fix the failed linking when building for OS X 10.7? I suppose this could be related to object visibility options as the serialization library is compiled with "-fvisibility=hidden" and "-fvisibility-inlines-hidden" options.
I'm sorry I can't help much. I do you mac os. I build and test the serialization library with xcode project generated by CMake. The xcode (and by extension Clang C++) has a huge number of options any one of which could be the reason that one can't link two modules. Note that I also test with the bjam command line which also has access to compile/link time switches. I test this with both gcc and clang I would suggest: a) Make sure you can build/test without the MACOSX_DEPLOYMENT_TARGET=10.7 setting. If this is indeed the problem you this would help you know. b) try b2 build and try CMake build Once you get one of these to work, add in the MACOSX_DEPLOYMENT_TARGET and try again. Basically this is trial and error to find what the magic "global variable" has to be set to make things work. Unfortunately, we have to do a lot of this these days - it's a fact of life. Robert Ramey
On Mon, Jun 26, 2017 at 12:55:21PM -0700, Robert Ramey wrote:
On 6/26/17 12:36 PM, Pavol Juhas via Boost-users wrote: ...
# -------------------------------------------------------------- $ export MACOSX_DEPLOYMENT_TARGET=10.7 $ ./bootstrap.sh $ ./b2 -j4 variant=release link=shared --with-serialization stage
$ c++ tarchive.cpp -I. -Lstage/lib -lboost_serialization Undefined symbols for architecture x86_64: ... # -------------------------------------------------------------- ... The only thing the test program (attached) does is to instantiate the boost::archive::binary_oarchive class. The procedure above works fine when MACOSX_DEPLOYMENT_TARGET is set to 10.9 or higher. ...
I'm sorry I can't help much. I do you mac os. I build and test the serialization library with xcode project generated by CMake. The xcode (and by extension Clang C++) has a huge number of options any one of which could be the reason that one can't link two modules. Note that I also test with the bjam command line which also has access to compile/link time switches. I test this with both gcc and clang
I would suggest:
a) Make sure you can build/test without the MACOSX_DEPLOYMENT_TARGET=10.7 setting. If this is indeed the problem you this would help you know.
Thank you Robert for a quick response. I have indeed tried different values for MACOSX_DEPLOYMENT_TARGET. The serialization library and the test program compiled and ran OK when deployment target was set to 10.9, 10.10 and when left unset. Presumably when MACOSX_DEPLOYMENT_TARGET is not present xcode builds for the current OS X version, which is 10.10 in my case. The link step fails when MACOSX_DEPLOYMENT_TARGET is 10.7 or 10.8.
b) try b2 build and try CMake build Once you get one of these to work, add in the MACOSX_DEPLOYMENT_TARGET and try again.
Would you have a pointer on how to build boost serialization with CMake? I was not able to quickly find such instructions at the boost page or in serialization repository. Perhaps CMake has different rules than bjam on setting compiler options when MACOSX_DEPLOYMENT_TARGET is in the environment. Thank you, Pavol
On 6/26/17 12:36 PM, Pavol Juhas via Boost-users wrote: ...
# -------------------------------------------------------------- $ export MACOSX_DEPLOYMENT_TARGET=10.7 $ ./bootstrap.sh $ ./b2 -j4 variant=release link=shared --with-serialization stage
$ c++ tarchive.cpp -I. -Lstage/lib -lboost_serialization Undefined symbols for architecture x86_64: ... # -------------------------------------------------------------- ... The only thing the test program (attached) does is to instantiate the boost::archive::binary_oarchive class. The procedure above works fine when MACOSX_DEPLOYMENT_TARGET is set to 10.9 or higher. ...
FYI, I was able to link with boost_serialization that was built for MACOSX_DEPLOYMENT_TARGET=10.7 after commenting symbol-visibility options in the library jamfile (patch attached). I guess when Mac OS X clang++ builds for older systems the symbol hiding works a bit too well and subsequently the linker cannot find anything at all. This is only a problem when building for older OS X versions. For OS X target versions 10.9 or higher the library works fine as is. Pavol
participants (2)
-
Pavol Juhas -
Robert Ramey