Re: [Boost-users] (was Re: 1.40.0 - 32_64 broken on OS X 10.6 Snow Leopard) (now ppc64 support removed with Xcode 3.2 on Snow Leopard.

Subject: Re: [Boost-users] (was Re: 1.40.0 - 32_64 broken on OS X 10.6 Snow Leopard) (now ppc64 support removed with Xcode 3.2 on Snow Leopard.
From: Boris Dušek (boris.dusek_at_[hidden])
Date: 2009-09-08 06:47:12

On Tue, Sep 8, 2009 at 7:34 AM, Vladimir Prus <vladimir_at_[hidden]>wrote:

> > architecture=combined if you remove the -arch ppc64 from
> > tools/darwin.jam:307-317).
>
> Just to clarify, you now have:
>
>        arch-addr-flags darwin OPTIONS : combined : 32_64 : -arch i386 -arch
> ppc -arch x86_64 ;
>
> and that builds "3-way" fat binary, and if you put back
>
>        -arch ppc64

it makes the compiler unhappy? How can I check if a compile is affected by
> this problem/change?
>

basically yes, but it's a bit more tricky: if you remove -arch ppc64 but do
not fix the -m64 issue, then -arch ppc64 still gets internally specified
inside  g++ because of the -m64 in combination with -arch ppc (as far as I
can tell), and you get the same compile error as with -arch ppc64 present.
But if you both remove -arch ppc64 *and* fix the -m64 issue, than it's
building fine (except for math - see below).

Not sure what you mean by ability to check. Do you want to know 1. how to
check a particular build (like what error messages to look for), or do you
want to know what 2. version of g++ it is that exhibits the problem?

1.
with -arch ppc64 missing, but -m64 not fixed (i.e. present), the following
happens:
darwin.compile.c++
bin.v2/libs/signals/build/darwin-4.2.1/release/address-model-32_64/architecture-combined/threading-multi/trackable.o
In file included from ./boost/config/no_tr1/utility.hpp:21,
                 from ./boost/config/select_stdlib_config.hpp:20,
                 from ./boost/config.hpp:40,
                 from ./boost/type_traits/add_const.hpp:13,
                 from ./boost/type_traits.hpp:13,
                 from ./boost/signals/trackable.hpp:13,
                 from libs/signals/src/trackable.cpp:12:
/usr/include/c++/4.2.1/utility:65:28: error: bits/c++config.h: No such file
or directory
... (many other errors)

with -arch ppc64 present, and -m64 still not fixed (i.e. present): the same
thing as above happens

with -arch ppc64 present and -m64 fixed (i.e. not present): the same thing
as above happens

Finally, with -arch ppc64 missing and -m64 fixed (i.e. not present):
compiles fine

as for 2., I am on Snow Leopard (OS X 10.6), using the default compiler for
Snow Leopard SDK, which is g++-4.2.

However, just now I tried specifying explicitely g++-4.0, and -arch ppc64
worked on that one file (creating a 4-way object file) when -m64 was not
present. When -m64 was present, it failed again (since -arch i386 -m64
produced one x86_64 output, -arch x86_64 produced second x86_64 output and
lipo cannot merge 2 same archs into one universal object file/binary). But
to be honest, I don't really know well what is the relationship between
compiler versions, SDK versions, targeted OS versions and architectures
supported etc., so I can't really suggest any "proper" solution (like using
different g++ version based on targeted OS X etc.).

> >             if $(model) = 32
> >             {
> >                 option = -m32 ;
> >             }
> >             else
> >             {
> >                 if $(model) = 32_64
> >                 {
> >                 }
> >                 else
> >                 {
> >                     option = -m64 ;
> >                 }
> >             }
>
> Oh, bummer. I imagine that a simpler change would be to have:
>
>            if $(model) = 32
>            {
>                option = -m32 ;
>            }
>             else if $(model) = 64
>            {
>                option = -m64 ;
>             }
>
> ?
>

You are right, I just did not want to get too fancy with an unfamiliar
programming language :-) (was not sure if this syntax was OK) (I tested your
variant and it obviously works)

However I experienced problem with boost.math_at_1.40, everything else seems to
build fine - only 2 targets failed, which I suppose are 2 math libraries. I
did not notice this since previously I was building only a subset of the
libraries. I pin-pointed the problem down to GCC's precompiled headers
(which math builds and uses) being architecture-dependent - see [1], section
"Architecture independence", and this compile error:

darwin.compile.c++.pch
bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-combined/threading-multi/../src/tr1/pch.hpp.gch
lipo: can't figure out the architecture type of:
/var/folders/hh/hh89RPWHGkKJgJC3Gy-ZZk+++TI/-Tmp-//ccVpqkGD.out

    "g++" -x c++-header -O3 -finline-functions -Wno-inline -Wall -dynamic
-no-cpp-precomp -gdwarf-2 -arch i386 -arch ppc -arch x86_64 -fPIC
 -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-combined/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-combined/threading-multi/../src/tr1/pch.hpp.gch...
...skipped
<pbin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-combined/threading-multi>assoc_laguerre.o
for lack of
<pbin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-combined/threading-multi>../src/tr1/pch.hpp.gch...

I checked that even if there are -arch i386 -arch x86_64 only the command
still fails, so the problem is not some Intel vs. PPC thing, but happens
always when more than 1 different -arch is specified. The pch compiles fine
for single architecture. I am really not sure how to fix this, there could
be however a workaround - disable pch on darwin with universal (=more than
1) archs - make it a "no-op" and automatically fall back to including and
recompiling needed headers in every file.

Boris

[1]: http://clang.llvm.org/docs/PTHInternals.html