[Boost-build] 32_64 build on OS X 10.6 fails when compiling PCH of boost.math (1.42 beta1)

Subject: [Boost-build] 32_64 build on OS X 10.6 fails when compiling PCH of boost.math (1.42 beta1)
From: Benjamin Prestele (benjamin.prestele_at_[hidden])
Date: 2010-01-24 05:21:27

Hi all,

I'm still experiencing problems with the 32_64 build of boost 1.42 beta (and also boost 1.40, 1.41) on OS X 10.6 using gcc 4.2.1. This seems to be caused by the use of an architecture dependent PCH in boost.math, as previously mentioned in a post by Boris Dušek on the boost mailing list.

For completeness: building with "./bjam -q toolset=darwin architecture=x86 address-model=32_64 stage" yields the error below. The same error also stops a 3-way fat binary build, i.e. building with "./bjam -q toolset=darwin --disable-long-double architecture=combined address-model=32_64 stage":

-- snip --
darwin.compile.c++.pch bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/threading-multi/../src/tr1/pch.hpp.gch
lipo: can't figure out the architecture type of: /var/folders/0o/0oER7sZpH88DmnLmfrTFXU+++TI/-Tmp-//ccCR0kY1.out

    "g++" -x c++-header -O3 -finline-functions -Wno-inline -Wall -dynamic -no-cpp-precomp -gdwarf-2 -fPIC -arch i386 -arch x86_64  -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG -I"." -I"libs/math/src/tr1" -c -o "bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/threading-multi/../src/tr1/pch.hpp.gch" "libs/math/build/../src/tr1/pch.hpp"

...failed darwin.compile.c++.pch bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/threading-multi/../src/tr1/pch.hpp.gch...
-- snip --

The only workaround I could figure out so far is to disable PCH usage altogether with "pch=off", or to skip the boost.math library, using "--without-math". Since both workarounds are not really great, are there any other solutions for this?

If I understand the previous discussions correctly, usage of architecture dependent PCH files is not possible the way boost.build currently creates fat binaries with the latest gcc on OS X, i.e. by issuing a single gcc command with multiple "-arch" flags. So I would guess that this will affect all projects referencing boost.math or containing similar PCHs themselves, when building fat binaries with boost.build.

Therefore wouldn't it make sense for future releases of boost.build to split the build process of fat binaries in such a way, that compilation of source files and linkage into lib/exe targets is done separately for each architecture (probably into separate directories), and fat binary creation is done only as a final post-processing step using the lipo tool? I believe that this is also the way the latest XCode 3.2 is doing it.

I have no clue how much work it would require to change boost.build in such a way, or wether this approach would raise new implications. But to me it seems like a conceptually much cleaner approach than putting everything into a single compiler call and adapting this for all possible combinations each time Apple decides to break something. I would also guess that this separation could ease diagnostics and adaptation with future releases of boost / boost build and the different types and versions of compilers on OSX (gcc, llvm, ..).

It would be great if someone involved with boost.build development and/or OSX could please comment on this.

Thanks & best regards,
Benjamin

---
Visit us at
FOE 2010 / January 20-22 / Tokyo Big Sight, Japan / East Hall 2-30
http://www.foe.jp/en/
Photonics West 2010 / January 23-28 / The Moscone Center, San Francisco, CA / Booth 4601-32
http://spie.org/photonics-west.xml