On Tue, Sep 8, 2009 at 7:34 AM, Vladimir Prus <firstname.lastname@example.org> wrote:
> architecture=combined if you remove the -arch ppc64 fromJust 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
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 happens:
In file included from ./boost/config/no_tr1/utility.hpp:21,
/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.).
Oh, bummer. I imagine that a simpler change would be to have:
> if $(model) = 32
> option = -m32 ;
> if $(model) = 32_64
> option = -m64 ;
else if $(model) = 64
if $(model) = 32
option = -m32 ;
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 email@example.com, 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 , section "Architecture independence", and this compile error:
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.