[Boost-users] 1.40.0 - 32_64 broken on OS X 10.6 Snow Leopard

[JungleCat]

Hi,
32_64 fat compilation is broken out of the box in 1.40.0 on OS X 10.6.

Others reported this here: http://groups.google.com/group/boost-list/browse_thread/thread/06c7e1f932219a31#

J

[Damien Hocking]

Just FYI: non-fat builds seem to be OK on 10.6 with

bjam --build-dir=./build32 --toolset=darwin address-model=32
architecture=x86 --stagedir=./stage32 stage
bjam --build-dir=./build64 --toolset=darwin address-model=64
architecture=x86 --stagedir=./stage64 stage

Damien

> ------------------------------------------------------------------------
>
> _______________________________________________
> Boost-users mailing list
> Boost...@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Vladimir Prus]

JungleCat wrote:

> Hi,
> 32_64 fat compilation is broken out of the box in 1.40.0 on OS X 10.6.

This is known..

> Others reported this here:
> http://groups.google.com/group/boost-list/browse_thread/thread/06c7e1f932219a31#

... and apparently you know that it's known. Do you have any further insights to
this problem -- which seems, on the face of it, like a compiler bug? Could you
bring this up with Apple support?

- Volodya

[JungleCat]

On Sep 4, 2009, at 10:31 PM, Vladimir Prus wrote:

> JungleCat wrote:
>
>> Hi,
>> 32_64 fat compilation is broken out of the box in 1.40.0 on OS X
>> 10.6.
>
> This is known..
>
>> Others reported this here:
>> http://groups.google.com/group/boost-list/browse_thread/thread/06c7e1f932219a31#

> ... and apparently you know that it's known. Do you have any further
> insights to
> this problem -- which seems, on the face of it, like a compiler bug?
> Could you
> bring this up with Apple support?

No insights yet but I believe this has to do with Xcode 3.2
introducing GCC 4.2 as the default compiler. I'll file an rdar if I
can confirm that it's their problem.

[JungleCat]

This isn't a compiler problem as I was able to compile OpenSSL into
32_64.

The error starts off when:

#include <exception>

is included from boost, date_time in my case:

/usr/include/c++/4.2.1/exception:42:28: error: bits/c++config.h: No
such file or directory

So:

/usr/include/c++/4.2.1/exception

Includes: bit/c++config.h

However bit/c++config.h doesn't exist, they are rooted in the /usr/
include/c++/4.2.1/i686-apple-darwin* /usr/include/c++/4.2.1/powerpc-
apple-darwin* and /usr/include/c++/4.2.1/x86_64-apple-darwin* folders.

I have not looked into the darwin.jam but I bet it's getting tricked
up with the SDK changes to paths, etc.. it's late, zzz..

Julian

On Sep 4, 2009, at 10:31 PM, Vladimir Prus wrote:

[Howard Hinnant]

On Sep 5, 2009, at 7:34 AM, JungleCat wrote:

> This isn't a compiler problem as I was able to compile OpenSSL into
> 32_64.
>
> The error starts off when:
>
> #include <exception>
>
> is included from boost, date_time in my case:
>
> /usr/include/c++/4.2.1/exception:42:28: error: bits/c++config.h: No
> such file or directory
>
> So:
>
> /usr/include/c++/4.2.1/exception
>
> Includes: bit/c++config.h
>
> However bit/c++config.h doesn't exist, they are rooted in the /usr/
> include/c++/4.2.1/i686-apple-darwin* /usr/include/c++/4.2.1/powerpc-
> apple-darwin* and /usr/include/c++/4.2.1/x86_64-apple-darwin* folders.
>
> I have not looked into the darwin.jam but I bet it's getting tricked
> up with the SDK changes to paths, etc.. it's late, zzz..

This is an include path problem. Unfortunately I don't know anything
about bjam or the boost build process. However I do know where you
can find bits/c++config.h.

For each platform (32/64, 10.4/5/6) there is a platform-specific
directory, e.g.:

/usr/include/c++/4.2.1/i686-apple-darwin10/ // 32 bit Snow Leopard
/usr/include/c++/4.2.1/x86_64-apple-darwin10/ // 64 bit Snow Leopard

Inside of each of these you will find bits/c++config.h. So you need
an include path to /usr/include/c++/4.2.1/<correct platform>.

Happy hunting! ;-)

-Howard

[Vladimir Prus]

Howard Hinnant wrote:

Do you suggest such a path should be manually passed to compiler? Still
counts as compiler bug by my book :-/

- Volodya

[Howard Hinnant]

I would have to see the command line being used to make any further
guesses as to where the problem lies. However on 10.6 I'm seeing the
following behavior:

$ cat test.cpp
#include <iostream>

int main()
{
std::cout << "Hello World\n";
}
$ g++ -arch i386 -arch x86_64 test.cpp
$ a.out
Hello World
$ nm -arch all a.out |grep a.out
a.out (for architecture i386):
a.out (for architecture x86_64):

-Howard

[JungleCat]

Simply doing this "g++ -arch ppc64 foo.cpp" breaks it. This is a ppc64
only problem. The SDK paths are MISSING for ppc64 and therefore
breaking g++ as I said in my previous email and this will require an
update from Apple, Inc. You can switch the SDK paths and it will work
or you can not use Xcode 3.2 because this wasn't a problem until Xcode
3.2 and the iPhone SDK additions.

Julian

[JungleCat]

ok, the problem is that you cannot compile c++ into ppc64 machine code on Snow Leopard because it doesn't ship with a ppc64 bit version of the SDK.

The following is the culprit in darwin.jam

arch-addr-flags darwin OPTIONS : combined : 64 : -arch x86_64 -arch ppc64 ;

My last post demonstrated the failure but you cannot build through Xcode because it will bail with the same error. My take is that Apple is dropping support for ppc64 but I have no confirmation other than they do not ship the ability to target this anymore.

Julian

[Damien Hocking]

OSX 10.6 doesn't install on a ppc Apple, I just tried it on my wife's
G5. Not supported anymore.

D

JungleCat wrote:
> ok, the problem is that you cannot compile c++ into ppc64 machine code
> on Snow Leopard because it doesn't ship with a ppc64 bit version of
> the SDK.
>
> The following is the culprit in darwin.jam
>

> arch-addr-flags darwin OPTIONS : combined : 64 : -arch x86_64 *-arch
> ppc64 *;

>> Boost...@lists.boost.org <mailto:Boost...@lists.boost.org>
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
> ------------------------------------------------------------------------

[JungleCat]

On Sep 5, 2009, at 9:13 PM, Damien Hocking wrote:

> OSX 10.6 doesn't install on a ppc Apple, I just tried it on my
> wife's G5. Not supported anymore.

This is the final transition to Intel, phase out PPC.

It was mainstream news: http://www.engadget.com/2009/06/10/snow-leopard-officially-puts-powerpc-macs-on-endangered-species/

There will need to be a rule changes to darwin.jam to fix this. If you
feel you want to hack it simply remove -arch ppc64 and build.

Julian

[Boris Dušek]

I think I got it with Snow Leopard and 32_64. First, looking at the lines with "arch-addr-flags", I realized what I really needed was architecture=x86 address-model=32_64 instead of architecture=combined address-model=32_64 (I needed Intel-only binaries, but I tested this also works for architecture=combined if you remove the -arch ppc64 from tools/darwin.jam:307-317). This removed the unfound bits/* headers error, but created a new one:

darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/threading-multi/file_descriptor.o

    "g++"  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -dynamic -no-cpp-precomp -gdwarf-2 -arch i386 -arch x86_64 -fPIC -m64  -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DNDEBUG  -I"." -c -o "bin.v2/libs/iostreams/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/threading-multi/file_descriptor.o" "libs/iostreams/src/file_descriptor.cpp"

lipo: /var/folders/hh/hh89RPWHGkKJgJC3Gy-ZZk+++TI/-Tmp-//ccXdF5pl.out and /var/folders/hh/hh89RPWHGkKJgJC3Gy-ZZk+++TI/-Tmp-//ccg03e1J.out have the same architectures (x86_64) and can't be in the same fat output file

...failed darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/threading-multi/file_descriptor.o...

I tried the same g++ command-line, but with "-m64" removed, and it worked and created the proper fat object file:

$ lipo -info bin.v2/libs/iostreams/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/threading-multi/file_descriptor.o 

Architectures in the fat file: bin.v2/libs/iostreams/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/threading-multi/file_descriptor.o are: i386 x86_64

I found that -m64 is being set in tools/gcc.jam based on the address-model at around line 377. So I added a check whether the model is 32_64, and add -m64 only if 32 is not set *and* 32_64 is not set:

            if $(model) = 32

            {

                option = -m32 ;

            }

            else

            {

                if $(model) = 32_64

                {

                }

                else

                {

                    option = -m64 ;

                }

            }

Then I compiled with architecture=x86 address-model=32_64 and got universal binaries as I needed:

$ lipo -info lib/libboost_iostreams-xgcc42-mt.dylib 

Architectures in the fat file: lib/libboost_iostreams-xgcc42-mt.dylib are: i386 ppc7400 x86_64

$ lipo -info lib/libboost_iostreams-xgcc42-mt-1_40.dylib

Architectures in the fat file: lib/libboost_iostreams-xgcc42-mt-1_40.dylib are: i386 x86_64

I also tried architecture=combined address-model=32_64 (after I removed -arch ppc64 from tools/darwin.jam), and confirmed that again, the "-m64" is what causes errors (I tested that it somehow forces 64-bit even if you previously specify 32-bit arch(s) with -arch option). With the same fix for -m64, this works:

In my opinion, more proper would be to:

1. in tools/gcc.jam:(352-383), if the toolset is darwin, don't setup address-model flags (-m32 and -m64), since these are taken care of in tools/darwin.jam (and in a correct way specific for Apple's gcc).

2. in tools/darwin.jam:(307-317), somehow check for the version of SDK (or version of OS X, don't know which one is more correct) and based on that, handle the unavailable -arch ppc64.

On a side note, I hope boost.build will soon be in Python, which I know well, since then I am willing to learn Boost.Build and submit proper patches without hacks :-)

Cheers,

Boris

[Boris Dušek]

2009/9/7 Boris Dušek <boris...@gmail.com>

Then I compiled with architecture=x86 address-model=32_64 and got universal binaries as I needed:

$ lipo -info lib/libboost_iostreams-xgcc42-mt.dylib 

Architectures in the fat file: lib/libboost_iostreams-xgcc42-mt.dylib are: i386 ppc7400 x86_64

$ lipo -info lib/libboost_iostreams-xgcc42-mt-1_40.dylib

Architectures in the fat file: lib/libboost_iostreams-xgcc42-mt-1_40.dylib are: i386 x86_64

I also tried architecture=combined address-model=32_64 (after I removed -arch ppc64 from tools/darwin.jam), and confirmed that again, the "-m64" is what causes errors (I tested that it somehow forces 64-bit even if you previously specify 32-bit arch(s) with -arch option). With the same fix for -m64, this works:

screwed this up, should be:

Then I compiled with architecture=x86 address-model=32_64 and got universal binaries as I needed:

[Vladimir Prus]

Boris Dušek wrote:

> I think I got it with Snow Leopard and 32_64. First, looking at the lines
> with "arch-addr-flags", I realized what I really needed was architecture=x86
> address-model=32_64 instead of architecture=combined address-model=32_64 (I
> needed Intel-only binaries, but I tested this also works for
> 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?

Oh, bummer. I imagine that a simpler change would be to have:

if $(model) = 32
{
option = -m32 ;
}

else if $(model) = 64
{
option = -m64 ;
}

?

> On a side note, I hope boost.build will soon be in Python, which I know
> well, since then I am willing to learn Boost.Build and submit proper patches
> without hacks :-)

I'm working on that; expect more progress by next Monday.

Thanks for investigating the problems -- this was very helpful.

- Volodya

[Boris Dušek]

On Tue, Sep 8, 2009 at 7:34 AM, Vladimir Prus <vlad...@codesourcery.com> 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...@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

[Manfred Schwind]

I followed all tricks mentioned in this list or other forums (e.g.
removing the -m64 option), but nothing worked for us. Building 32-Bit
and 64-Bit at the same time seems to be broken.
But I managed how to build a 4-way universal binary on Snow Leopard:
just build every architecture separately and afterwards put everything
together using the lipo tool.

I wrote a blog article about how we build the 4-way universal binaries
of Boost on Snow Leopard for our needs:

http://www.mani.de/backstage/?p=324

Regards,
Mani

[Vladimir Prus]

Manfred Schwind wrote:

> I followed all tricks mentioned in this list or other forums (e.g.
> removing the -m64 option), but nothing worked for us. Building 32-Bit
> and 64-Bit at the same time seems to be broken.
> But I managed how to build a 4-way universal binary on Snow Leopard:
> just build every architecture separately and afterwards put everything
> together using the lipo tool.

How does that agree with reports by others that 64-bit PPC is just
not supported with 10.5 SDK?

- Volodya

[Manfred Schwind]

> How does that agree with reports by others that 64-bit PPC is just
> not supported with 10.5 SDK?

As far as I know 64-bit PPC is not supported by the 10.6 SDK (Snow
Leopard), but we are using the 10.5 SDK (Leopard).
When installing Xcode there are multiple SDKs installed.

Additionally we are using GCC 4.0 instead of 4.2, because we want to
support Mac OS X 10.4 (Tiger) as minimum OS. When compiling with GCC
4.2 the generated code is for "ppc7400" that means "G4 Macs" and
greater; but Tiger also runs on "G3 Macs". But this may not be of much
importance anymore.

If you look at our script you see that we're using the following
options for bjam:

toolset=darwin-4.0: Use darwin toolset with GCC 4.0.
macosx-version=10.5: Use the 10.5 SDK.
macosx-version-min=10.4: Minimum supported OS is 10.4.

Regards,
Mani

[Dane Springmeyer]

Hello Mani,

Nice write-up and I'm glad you've got things working.

I've been in this same situation as I am building univeral binaries
that need boost libs on both 10.5 and 10.6.

I've been able to do this in one build command using the patches here:

http://trac.macports.org/browser/trunk/dports/devel/boost/files/patch-tools-build-v2-tools-gcc.jam.diff

http://trac.macports.org/browser/trunk/dports/devel/boost/files/patch-tools-build-v2-tools-darwin.jam.diff

See also:

http://trac.macports.org/ticket/21408

Essentially it came down to:

1) providing the right set of -arch flags for a 10.5 or 10.6 (no -arch
ppc64) system.

2) avoiding the usage of the -m64 type flags (does Boost specifically
need these in any way?), since they seem to cause problems when
conflicting with the (multiple) apple only -arch flags that can be
used to build (all in one fell swoop) FAT universal libs.

-m32
-m64
Generate code for a 32-bit or 64-bit environment. The 32-
bit environment sets int, long and
pointer to 32 bits and generates code that runs on any
i386 system. The 64-bit environment sets
int to 32 bits and long and pointer to 64 bits and
generates code for AMD's x86-64 architecture.
For darwin only the -m64 option turns off the -fno-pic and
-mdynamic-no-pic options.

Dane