1.40.0 - 32_64 broken on OS X 10.6 Snow Leopard
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/06c7e1f932219... J
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 JungleCat wrote:
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/06c7e1f932219...
J ------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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/06c7e1f932219...
... 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
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/06c7e1f932219...
... 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.
- Volodya
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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:
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/06c7e1f932219...
... 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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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
Howard Hinnant wrote:
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>.
Do you suggest such a path should be manually passed to compiler? Still counts as compiler bug by my book :-/ - Volodya
On Sep 5, 2009, at 3:32 PM, Vladimir Prus wrote:
Howard Hinnant wrote:
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>.
Do you suggest such a path should be manually passed to compiler? Still counts as compiler bug by my book :-/
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
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 On Sep 5, 2009, at 3:14 PM, Howard Hinnant wrote:
On Sep 5, 2009, at 3:32 PM, Vladimir Prus wrote:
Howard Hinnant wrote:
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>.
Do you suggest such a path should be manually passed to compiler? Still counts as compiler bug by my book :-/
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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 On Sep 5, 2009, at 3:14 PM, Howard Hinnant wrote:
On Sep 5, 2009, at 3:32 PM, Vladimir Prus wrote:
Howard Hinnant wrote:
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>.
Do you suggest such a path should be manually passed to compiler? Still counts as compiler bug by my book :-/
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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 *;
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
On Sep 5, 2009, at 3:14 PM, Howard Hinnant wrote:
On Sep 5, 2009, at 3:32 PM, Vladimir Prus wrote:
Howard Hinnant wrote:
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>.
Do you suggest such a path should be manually passed to compiler? Still counts as compiler bug by my book :-/
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org mailto:Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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... 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
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 *;
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
On Sep 5, 2009, at 3:14 PM, Howard Hinnant wrote:
On Sep 5, 2009, at 3:32 PM, Vladimir Prus wrote:
Howard Hinnant wrote:
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>.
Do you suggest such a path should be manually passed to compiler? Still counts as compiler bug by my book :-/
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org mailto:Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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
On Sun, Sep 6, 2009 at 2:34 AM, 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
2009/9/7 Boris Dušek
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: $ 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: $ lipo -info lib/libboost_iostreams-xgcc42-mt.dylib Architectures in the fat file: lib/libboost_iostreams-xgcc42-mt.dylib are: i386 ppc7400 x86_64
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?
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 ; } }
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
On Tue, Sep 8, 2009 at 7:34 AM, Vladimir Prus
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@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
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
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
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
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-... http://trac.macports.org/browser/trunk/dports/devel/boost/files/patch-tools-... 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 On Oct 15, 2009, at 1:40 AM, 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.
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (7)
-
Boris Dušek -
Damien Hocking -
Dane Springmeyer -
Howard Hinnant -
JungleCat -
Manfred Schwind -
Vladimir Prus