[Boost-users] Trouble building 1.5.4 on OS X 10.6

Subject: [Boost-users] Trouble building 1.5.4 on OS X 10.6
From: Jo Meder (jomeder_at_[hidden])
Date: 2013-08-22 01:57:45

Hi,

I'm having trouble building 1.5.4 on OS X 10.6 for Intel only Universal builds (32 and 64 bit). This is my command line for b2:

./b2 macosx-version=10.6 macosx-version-min=10.6 threading=multi architecture=x86 address-model=32_64

I've also tried a simpler command line just specifying the architecture and address model, same results.

Originally I was having trouble building all the libraries, in particular the thread lib wasn't building. Now mysteriously it is. However the libraries are being built with the ppc and ppc64 architectures as well as i386 and x86_64, which doesn't seem right given the options I'm specifying. You can see the unwanted archs in the build lines too, for example:

"g++-4.0"  -ftemplate-depth-128 -arch x86_64 -arch i386 -arch ppc64 -arch ppc -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -Wno-long-double -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -arch i386 -arch x86_64  -DBOOST_ALL_NO_LIB=1 -DNDEBUG  -I"." -c -o "bin.v2/libs/context/build/darwin-4.0/release/address-model-32_64/architecture-x86/link-static/macosx-version-min-10.6/macosx-version-10.6/threading-multi/unsupported.o" "libs/context/src/unsupported.cpp"

There are 4 arch flags near the start for x86_64, i386, ppc64 and ppc. There are also two more for x86_64 and i386 further on, which I assume are the ones the darwin.jam file has added based on my options passed to b2.

I'm guessing these build lines are only being shown when there's a problem as there certainly isn't one for every file, but I assume they're representative.

Now the libs seem to be building but I'm getting link errors from libboost_thread:

Undefined symbols:
  "boost::thread_detail::enter_once_region(boost::once_flag&)", referenced from:
      boost::detail::set_current_thread_data(boost::detail::thread_data_base*)in libboost_thread.a(thread.o)
      boost::detail::get_current_thread_data()     in libboost_thread.a(thread.o)
      _thread_proxy in libboost_thread.a(thread.o)
      _thread_proxy in libboost_thread.a(thread.o)
      boost::(anonymous namespace)::make_external_thread_data()                                                in libboost_thread.a(thread.o)
  "boost::thread_detail::commit_once_region(boost::once_flag&)", referenced from:
      boost::detail::set_current_thread_data(boost::detail::thread_data_base*)in libboost_thread.a(thread.o)
      boost::detail::get_current_thread_data()     in libboost_thread.a(thread.o)
      _thread_proxy in libboost_thread.a(thread.o)
      _thread_proxy in libboost_thread.a(thread.o)
      boost::(anonymous namespace)::make_external_thread_data()                                                in libboost_thread.a(thread.o)
  "boost::thread_detail::rollback_once_region(boost::once_flag&)", referenced from:
      boost::detail::set_current_thread_data(boost::detail::thread_data_base*)in libboost_thread.a(thread.o)
      boost::detail::get_current_thread_data()     in libboost_thread.a(thread.o)
      _thread_proxy in libboost_thread.a(thread.o)
      _thread_proxy in libboost_thread.a(thread.o)
      boost::(anonymous namespace)::make_external_thread_data()                                                in libboost_thread.a(thread.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

I saw there was a problem building the thread lib on OS X so I've added:

#define BOOST_THREAD_DONT_USE_ATOMIC

to boost/config/user.hpp. That seems related because in the headers that appears to control which file with the enter_once_region and so on functions gets included.

If anyone has any insight I'd appreciate it.

Regards,

Jo Meder