Cross-Posting: Anyone know how to force a universal or at least Intel static build?
I already tried the users list for Boost so I am cross-posting this. When I perform an "out-of-the-box" build on my Macbook Pro (Intel dual core) on Leopard (10.5) i get a motley collection of ppc and intel binaries that are useless on my Intel-based system unless I want to use the dynamic libraries only. None of the libraries are universal binaries and only the dynamic libraries are for the i386 architecture (see lipo output below). $lipo -detailed_info libboost_regex* input file libboost_regex-1_34_1.a is not a fat file input file libboost_regex-1_34_1.dylib is not a fat file input file libboost_regex-d-1_34_1.a is not a fat file input file libboost_regex-d-1_34_1.dylib is not a fat file input file libboost_regex-d.a is not a fat file input file libboost_regex-mt-1_34_1.a is not a fat file input file libboost_regex-mt-1_34_1.dylib is not a fat file input file libboost_regex-mt-d-1_34_1.a is not a fat file input file libboost_regex-mt-d-1_34_1.dylib is not a fat file input file libboost_regex-mt-d.a is not a fat file input file libboost_regex-mt.a is not a fat file input file libboost_regex.a is not a fat file Non-fat file: libboost_regex-1_34_1.a is architecture: ppc7400 Non-fat file: libboost_regex-1_34_1.dylib is architecture: i386 Non-fat file: libboost_regex-d-1_34_1.a is architecture: ppc7400 Non-fat file: libboost_regex-d-1_34_1.dylib is architecture: i386 Non-fat file: libboost_regex-d.a is architecture: ppc7400 Non-fat file: libboost_regex-mt-1_34_1.a is architecture: ppc7400 Non-fat file: libboost_regex-mt-1_34_1.dylib is architecture: i386 Non-fat file: libboost_regex-mt-d-1_34_1.a is architecture: ppc7400 Non-fat file: libboost_regex-mt-d-1_34_1.dylib is architecture: i386 Non-fat file: libboost_regex-mt-d.a is architecture: ppc7400 Non-fat file: libboost_regex-mt.a is architecture: ppc7400 Non-fat file: libboost_regex.a is architecture: ppc7400 I made the assumption that Boost would, as a default, build for the native architecture it was building one since most of the other libraries I use have been doing that for nearly 2 years. My mistake. To have it build ppc on an intel platform--that was completely unexpected at this late date. The jam user configuration is very simple gives not hint of why bjam builds static ppc and dynamic intel binaries. ugh. What a mystery to someone who knows little about bjam. Searching the Boost site for the key word "universal binaries" found nothing. Searching for "universal OS X" gave four generic uses of the word "universal" but nothing of help. Anybody have any experience building Boost as a universal library set? If not... It's been over a year since I had to hack a build so I need to refresh my memory. It my well be time to pour another cup of java, take the red pill, and see how deep the rabbiit hole goes.
Daniel Lord wrote:
I already tried the users list for Boost so I am cross-posting this. When I perform an "out-of-the-box" build on my Macbook Pro (Intel dual core) on Leopard (10.5) i get a motley collection of ppc and intel binaries that are useless on my Intel-based system unless I want to use the dynamic libraries only.
Daniel, I don't know anything about Darwin, but if you add -d2 to the bjam invocation then it'll print the actual command lines used and give you a chance to diagnose what's going on (if you're building via configure/make then you'll have to edit the makefile to do this). Actually if you just extract the bjam invocation from the makefile and then add the options: -d2 -n -a it'll print all the command lines without actually building anything. Also remember that the regex library is "just a bunch of sources", you can build it anyway you want using any tool you want (or add the source directly to your project if you'd rather). The source is in libs/regex/src BTW. Most other Boost libraries are the same too. HTH, John.
John, thanks for the tips. I figured it out and got it to work (partially--only compiles for OS X i386 and not the ppc700 needed for a universal 'fat' binary). I then discovered there is an another way though a bit less direct--Adobe has a patch you can get by going to Source Forge and downloading the Adobe Source Libraries (ASL). It adds options for architecture (fat, i386, ppc700), SDK version of OS X gong back to 10.2 (which is moot as Leopard support only 10.5 and 10.4 now), and deployment option like stripping etc. Is it worth submitting a patch? I'll read up on how to submit a patch and documentation and then I'll submit. If anyone cares I will, otherwise I'll just put more detail in the wiki which I just now realized might already have this answer although Google didn't find it. In the meantime, here is what I did. 1. to make bjam build for the Intel platform on Intel Macs: Modify darwin.jam by addling the following lines in the init rule: flags darwin CFLAGS : -arch i386 -arch ppc ; flags darwin LINKFLAGS : -arch i386 -arch ppc ; flags darwin LINKFLAGS <runtime-link>static : -static-libgcc ; flags darwin CFLAGS <debug-symbols>on : -g ; flags darwin LINKFLAGS <debug-symbols>on : -g ; This results in static and dynamic libraries built for the i386 architecture but not universal binaries because the ar tool cannot build those. 2. So I tried libtool which can build them by again modifying the darwin.jamfile: #ar -c -r -s $(ARFLAGS) "$(<:T)" "$(>:T)" libtool -static -dynamic -o "$(<:T)" $(ARFLAGS) "$(>:T)" But so far, although Boost now build the libraries for the right architecture, it doesn't build universal binaries which can run on either architecture, ppc or i386. I'll keep trying here and there since universal is better than platform-specific. But at least Boost is useable on an Intel Mac now. I guess I should eventually get 64-bit working for both platfroms for a 'quad' universal binary ;-). On 11/10/07, John Maddock < john@johnmaddock.co.uk > wrote:
Daniel Lord wrote:
I already tried the users list for Boost so I am cross-posting this. When I perform an "out-of-the-box" build on my Macbook Pro (Intel dual core) on Leopard (10.5) i get a motley collection of ppc and intel binaries that are useless on my Intel-based system unless I want to use the dynamic libraries only.
Daniel, I don't know anything about Darwin, but if you add -d2 to the bjam invocation then it'll print the actual command lines used and give you a chance to diagnose what's going on (if you're building via configure/make then you'll have to edit the makefile to do this). Actually if you just extract the bjam invocation from the makefile and then add the options: -d2 -n -a it'll print all the command lines without actually building anything.
Also remember that the regex library is "just a bunch of sources", you can build it anyway you want using any tool you want (or add the source directly to your project if you'd rather). The source is in libs/regex/src BTW. Most other Boost libraries are the same too.
HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 12/11/2007 15:50, Daniel Lord wrote:
John, thanks for the tips. I figured it out and got it to work (partially--only compiles for OS X i386 and not the ppc700 needed for a universal 'fat' binary).
I then discovered there is an another way though a bit less direct--Adobe has a patch you can get by going to Source Forge and downloading the Adobe Source Libraries (ASL). It adds options for architecture (fat, i386, ppc700), SDK version of OS X gong back to 10.2 (which is moot as Leopard support only 10.5 and 10.4 now), and deployment option like stripping etc.
Is it worth submitting a patch? I'll read up on how to submit a patch and documentation and then I'll submit. If anyone cares I will, otherwise I'll just put more detail in the wiki which I just now realized might already have this answer although Google didn't find it.
Hey Daniel, I haven't installed Leopard yet but am going to need this in the future, so thank you for the howto and keep us posted. I don't mind following your instructions, though a patch would be great, once you figured out the whole solution. Regards, Niko
[...]
Niko Demmel wrote:
On 12/11/2007 15:50, Daniel Lord wrote:
Is it worth submitting a patch? I'll read up on how to submit a patch and documentation and then I'll submit.
I don't mind following your instructions, though a patch would be great, once you figured out the whole solution.
There's been a patch for some time now <http://svn.boost.org/trac/boost/ticket/989>. But no one has done the changes I requested to it, hence it's never been applied. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Nov 12, 2007 7:47 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
There's been a patch for some time now <http://svn.boost.org/trac/boost/ticket/989>. But no one has done the changes I requested to it, hence it's never been applied.
Hi Rene, It just so happens that I'm digging into my patch once more. I tried implementing your suggested modifications. A couple of questions arose: gcc on Mac OS X/darwin offers the Apple-only -arch option. " -arch arch Compile for the specified target architecture arch. The allowable values are i386, ppc and ppc64. Multiple options work, and direct the compiler to produce ``universal'' binaries including object code for each architecture specified with -arch. This option only works if assembler and libraries are available for each architecture specified. (APPLE ONLY) " This option is separate from the -march option: -arch and -march are two separate compiler flags, the latter with established bjam/gcc usage. That is, if I replace my <arch> feature with an (enahnced) <architecture> feature from builtin.jam, the existing gcc options involving -march are eclipsed. The same holds for <address-model>. For example, <address-model>32 maps to -m32 under 'normal' gcc, whereas I would commandeer <architecture>power/<address-model>32, emitting -arch ppc instead. Is this what you want? - Mat
Mat Marcus wrote:
On Nov 12, 2007 7:47 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
There's been a patch for some time now <http://svn.boost.org/trac/boost/ticket/989>. But no one has done the changes I requested to it, hence it's never been applied.
It just so happens that I'm digging into my patch once more. I tried
Oh, good :-)
implementing your suggested modifications. A couple of questions arose:
gcc on Mac OS X/darwin offers the Apple-only -arch option.
" -arch arch Compile for the specified target architecture arch. The allowable [...] "
This option is separate from the -march option: -arch and -march are two separate compiler flags, the latter with established bjam/gcc usage. That is, if I replace my <arch> feature with an (enahnced) <architecture> feature from builtin.jam, the existing gcc options involving -march are eclipsed. The same holds for <address-model>. For example, <address-model>32 maps to -m32 under 'normal' gcc, whereas I would commandeer <architecture>power/<address-model>32, emitting -arch ppc instead. Is this what you want?
If that's what works for the Apple GCC... Yes. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Daniel Lord wrote:
John, thanks for the tips. I figured it out and got it to work (partially--only compiles for OS X i386 and not the ppc700 needed for a universal 'fat' binary).
I then discovered there is an another way though a bit less direct--Adobe has a patch you can get by going to Source Forge and downloading the Adobe Source Libraries (ASL). It adds options for architecture (fat, i386, ppc700), SDK version of OS X gong back to 10.2 (which is moot as Leopard support only 10.5 and 10.4 now), and deployment option like stripping etc.
Is it worth submitting a patch?
Definitely, go to svn.boost.org and submit a Track issue with the component set to "build".
I'll read up on how to submit a patch and documentation and then I'll submit. If anyone cares I will, otherwise I'll just put more detail in the wiki which I just now realized might already have this answer although Google didn't find it.
In the meantime, here is what I did. 1. to make bjam build for the Intel platform on Intel Macs:
Modify darwin.jam by addling the following lines in the init rule: flags darwin CFLAGS : -arch i386 -arch ppc ; flags darwin LINKFLAGS : -arch i386 -arch ppc ; flags darwin LINKFLAGS <runtime-link>static : -static-libgcc ; flags darwin CFLAGS <debug-symbols>on : -g ; flags darwin LINKFLAGS <debug-symbols>on : -g ;
This results in static and dynamic libraries built for the i386 architecture but not universal binaries because the ar tool cannot build those.
2. So I tried libtool which can build them by again modifying the darwin.jamfile: #ar -c -r -s $(ARFLAGS) "$(<:T)" "$(>:T)" libtool -static -dynamic -o "$(<:T)" $(ARFLAGS) "$(>:T)"
But so far, although Boost now build the libraries for the right architecture, it doesn't build universal binaries which can run on either architecture, ppc or i386. I'll keep trying here and there since universal is better than platform-specific. But at least Boost is useable on an Intel Mac now. I guess I should eventually get 64-bit working for both platfroms for a 'quad' universal binary ;-).
Thanks for reporting back, if you can place whatever patches and info you have on the Track so this doesn't get lost, that would be excellent. Thanks, John.
participants (5)
-
Daniel Lord -
John Maddock -
Mat Marcus -
Niko Demmel -
Rene Rivera