Boost logo

Boost Users :

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?

with -arch ppc64 missing, but -m64 not fixed (i.e. present), the following
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:

lipo: can't figure out the architecture type of:

    "g++" -x c++-header -O3 -finline-functions -Wno-inline -Wall -dynamic
-no-cpp-precomp -gdwarf-2 -arch i386 -arch ppc -arch x86_64 -fPIC
-DNDEBUG -I"." -I"libs/math/src/tr1" -c -o

...failed darwin.compile.c++.pch
for lack of

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.



Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at