Opened 11 years ago
Closed 10 years ago
#39809 closed defect (fixed)
boost @1.54.0 fails to upgrade
Reported by: | nonstop.server@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.3 |
Keywords: | tiger leopard snowleopard | Cc: | cooljeanius (Eric Gallager), mkae (Marko Käning), gnw3, mndavidoff (Monte Davidoff), bitpup, deesto (John S. De Stefano Jr.), jdgleeson, udbraumann, mklein-de (Michael Klein), mdbecque@…, blair (Blair Zajac), josephsacco, ryandesign (Ryan Carsten Schmidt), revast@…, lubodiakov@…, xanda-escuyer (xanda), khepler, potmj (Michael Pot), dgonyier (Dwaine Gonyier) |
Port: | boost |
Description
Upgrading boost fails with error message:
...failed updating 20 targets... ...skipped 18 targets... ...updated 1931 targets... Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_boost/boost/work/boost_1_54_0" && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_boost/boost/work/boost_1_54_0/b2 -d2 --layout=tagged --debug-configuration --user-config=user-config.jam -sBZIP2_INCLUDE=/opt/local/include -sBZIP2_LIBPATH=/opt/local/lib -sEXPAT_INCLUDE=/opt/local/include -sEXPAT_LIBPATH=/opt/local/lib -sZLIB_INCLUDE=/opt/local/include -sZLIB_LIBPATH=/opt/local/lib -sICU_PATH=/opt/local link=static,shared architecture=x86 address-model=32 variant=debug,release link=shared threading=multi Exit code: 1
Version Information:
Mac OS Version: ProductName: Mac OS X ProductVersion: 10.5.8 BuildVersion: 9L31a Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 Xcode Version: Xcode 3.1.4 Component versions: DevToolsCore-1204.0; DevToolsSupport-1186.0 BuildVersion: 9M2809 Macports Version: Version: 2.1.3
Attachments (4)
Change History (49)
Changed 11 years ago by nonstop.server@…
Attachment: | main.log.bz2 added |
---|
comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | tiger snowleopard added |
---|
comment:5 follow-ups: 6 8 14 Changed 11 years ago by gnw3
Replying to nonstop.server@…:
Upgrading boost fails with error message:
...failed updating 20 targets... ...skipped 18 targets... ...updated 1931 targets... [...]Version Information:
Mac OS Version: ProductName: Mac OS X ProductVersion: 10.5.8 BuildVersion: 9L31a Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 Xcode Version: Xcode 3.1.4 Component versions: DevToolsCore-1204.0; DevToolsSupport-1186.0 BuildVersion: 9M2809 Macports Version: Version: 2.1.3
I have Xcode 3.2.6. The default build used
$ /usr/bin/g++-4.2 --version i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
With this, I got:
:info:build ...failed updating 6 targets... :info:build ...skipped 4 targets... :info:build ...updated 1081 targets...
I also tried
$ sudo port clean boost $ sudo port install boost configure.compiler=llvm-gcc-4.2
This also failed for the same numbers of targets, so then I tried
$ sudo port clean boost $ sudo port install boost configure.compiler=macports-gcc-4.8
This installed cleanly.
comment:6 Changed 11 years ago by mkae (Marko Käning)
Replying to gnwiii@…:
Herewith I verify that boost builds fine with Xcode 3.2.6 on Snow Leopard when using gcc 4.8!
comment:8 Changed 11 years ago by nonstop.server@…
Replying to gnwiii@…:
Thank you for your advice!
I was also able to upgrade boost successfully using compiler gcc 4.8.
comment:11 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Using a MacPorts gcc compiler is not a viable solution. If no Xcode compiler is suitable, use clang 3.3.
comment:12 follow-up: 13 Changed 11 years ago by mkae (Marko Käning)
Sorry, that I seemingly senselessly posted #39822, but I was completely occupied with the litecoin port so that I didn't think about this boost issue which I had myself worked around using gcc 4.8.
OK, you're saying using gcc isn't an option on Snow Leopard... Why is clang 3.3 to be preferred?
comment:13 Changed 11 years ago by larryv (Lawrence Velázquez)
Replying to mk@…:
OK, you're saying using gcc isn't an option on Snow Leopard... Why is clang 3.3 to be preferred?
It wouldn’t break the universal variant, for one.
comment:14 Changed 11 years ago by devernay (Frédéric Devernay)
This is due to the new Boost.Log library relying on TR1 result_of protocol, which is unimplemented in GCC 4.2. This probably won't be fixed https://svn.boost.org/trac/boost/ticket/8769 unless somebody wants to fix it https://svn.boost.org/trac/boost/ticket/8639 .
Here's the homebrew pull request I got this information from https://github.com/mxcl/homebrew/pull/20947 .
clang 3.3 is probably the most viable option, as it is for all ports which will break in the future because they are using C++11 features.
Keeping the universal variant is an important issue, since the concerned OS versions may require it (universal only means something up to 10.6, after that all machines were 64-bits intel anyway).
comment:16 Changed 11 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:18 Changed 11 years ago by deesto (John S. De Stefano Jr.)
Fix in 1.54.0 confirmed for me on Snow Leopard. Thank you.
comment:19 follow-up: 24 Changed 11 years ago by devernay (Frédéric Devernay)
Unfortunately, clang-3.3 cannot compile even a simple program using stdout or stderr on PPC, see #39052 which is a wontfix. The boost build on Leopard PPC fails very early with:
/opt/local/bin/clang-mp-3.3 -o bootstrap/jam0 command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathsys.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c class.c cwd.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c ... ld: absolute address to symbol ___stdoutp in a different linkage unit not supported in _debug_compile from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_boost/boost/work/.tmp/compile-FLho17.o collect2: ld returned 1 exit status clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
Of course, g++-4.2 works in this case, but clang-3.0 works too! I will try clang-3.1 and clang-3.2 next week and I will report.
This means that, probably, a clang version older than 3.3 will have to be used for Leopard.
comment:20 Changed 11 years ago by devernay (Frédéric Devernay)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:23 Changed 11 years ago by devernay (Frédéric Devernay)
See #39761 for linking problems on PPC with llvm-3.3
comment:24 follow-up: 25 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to frederic.devernay@…:
Unfortunately, clang-3.3 cannot compile even a simple program using stdout or stderr on PPC, see #39052 which is a wontfix. ... This means that, probably, a clang version older than 3.3 will have to be used for Leopard.
No. ppc support is quite experimental in llvm.
I suggest ppc users just use configure.compiler=macports-gcc-4.8
comment:25 follow-up: 26 Changed 11 years ago by udbraumann
Replying to jeremyhu@…:
I suggest ppc users just use configure.compiler=macports-gcc-4.8
Hmm, today I have tried to install gcc48 on my leopard ppc, but I got this frustrating message at once:
$ sudo port -v install gcc48 Error: gcc48 cannot be installed for the configured build_arch 'ppc' because it only supports the arch(s) 'i386 x86_64'. To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port gcc48 failed
So for boost we are in a deadlock, if llvm-3.3 and clang-3.3 are experimental on ppc (at least need lots of ressources and may be tricky to be built), but boost now requires llvm-3.3, and the alternative using gcc48 explicitly is impossible, we have reached the end of the road for boost on ppc, have we?
comment:26 follow-up: 27 Changed 11 years ago by jdgleeson
Replying to braumann@…:
...and the alternative using gcc48 explicitly is impossible...
There is still room for hope. If you delete line 158 "supported_archs i386 x86_64
" in the gcc48 Portfile, gcc48 will build on PPC. Since I already have a gcc48 built on PPC, I'm going to try to build boost 1.54 with it now.
comment:27 Changed 11 years ago by larryv (Lawrence Velázquez)
Replying to jdgleeson@…:
There is still room for hope. If you delete line 158 "
supported_archs i386 x86_64
" in the gcc48 Portfile, gcc48 will build on PPC.
That line was added in r93033 in response to #34385. If GCC 4.8.1 builds correctly on PowerPC now, please comment on that ticket.
comment:28 follow-up: 39 Changed 11 years ago by jdgleeson
The first time I tried building with gcc48 failed with the error message
g++-mp-4.8: error: unrecognized command line option '-arch'
I got past this problem by commenting out the line
options = -arch ppc ;
in boost_1_54_0/tools/build/v2/tools/darwin.jam
in the work directory.
In case this hack doesn't make it obvious, I am completely unfamiliar with
the boost build system.
I resumed the build and encountered more problems that I have no idea how to fix:
:info:build ...failed updating 5 targets... :info:build ...skipped 9 targets... :info:build ...updated 670 targets...
The log file is attached.
Changed 11 years ago by jdgleeson
Attachment: | main_gcc48.log.bz2 added |
---|
using gcc48 after hack to remove -arch option
comment:29 Changed 11 years ago by devernay (Frédéric Devernay)
another option would be to simply disable Boost.Log on PPC and keep going with the default compiler.
Boost.Context is already disabled that way, why not add also disable Boost.Log?
and remove the compiler blacklist on ppc
something like
platform powerpc { # clang on powerpc (as of 3.3) is still experimental configure.args-append --without-libraries=context,log compiler.blacklist-delete llvm-gcc-4.2 apple-gcc-4.2 gcc-4.2 gcc-4.0 apple-gcc-4.0 gcc-3.3 compiler.fallback-delete macports-clang-3.3 }
comment:31 Changed 11 years ago by udbraumann
I need to tell that even with a working macports-clang-3.3 I was not able to build boost @1.54.0 on my 10.5.8 ppc G4. It already fails in the very beginning when processing boostrap.sh. In boostrap.log this error is being reported:
ld: absolute address to symbol ___stdoutp in a different linkage unit not supported in _debug_compile from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_boost/boost/work/.tmp/compile-7WwBRc.o
I will attach both the main.log as well as the bootstrap.log
comment:33 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | blair@… drjesacco@… ryandesign@… revast@… lubodiakov@… added |
---|
comment:34 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | xanda@… added |
---|
Has duplicate #41901.
comment:38 Changed 11 years ago by potmj (Michael Pot)
Cc: | fmw@… added |
---|
Cc Me! As a dependent, trying to install geda-gaf 10.5.8 Intel
comment:39 follow-up: 40 Changed 11 years ago by udbraumann
Replying to jdgleeson@…:
... I got past this problem by commenting out the line
options = -arch ppc ;in
boost_1_54_0/tools/build/v2/tools/darwin.jam
in the work directory.
Your hack has inspired me to find a work-around which finally has lead to a successful boost
build on my Powerbook G4.
First I had noticed that gcc4.8 now smoothly builds on my 10.5.8 PPC (meanwhile we have gcc48 @4.8.2_0
). Suddenly I got aware that gcc48 can be enabled to compile C++11 code, which in turn was one of the arguments to preset clang-3.3 @3.3_2
as compiler for boost
. However, PPC support of clang
is and probably will remain insufficient for practical usage, clang-3.3
already fails during configuration of boost @1.55.0_2
. So I assumed that gcc48
with C++11 support enabled should work to build boost
.
To remove previous tests first I cleaned up:
sudo port clean boost
Since I was aware that building with gcc48
will lead to an error complaining that -arch
is not an accepted switch, I just did the configuration without building:
sudo port configure boost configure.compiler=macports-gcc-4.8
Once this had completed the hack I have applied for my "proof of concept" was just to replace
options = -arch ppc ;
with
options = -std=c++11 ;
in boost_1_55_0/tools/build/v2/tools/darwin.jam
. Note that root privileges are required to edit darwin.jam
.
Then I just continued building:
sudo port install boost configure.compiler=macports-gcc-4.8
Not sure if the configure.compiler
is essential here or not, probably not.
Some hours later, boost
was successfully installed!
I leave it to someone more experienced to modify the boost
portfile or even other files in order to automate the few steps I was explaining above. For the sake of PPC users it really would be nice to see my little recipe implemented that circumvents a clang
usage.
comment:40 Changed 11 years ago by josephsacco
Replying to braumann@…:
You have clearly selected the correct option for building boost on a PPC using gcc rather than clang.
Proof by existence:
Dual G4 based PowerMac OS X 10.5.8
boost @1.55.0_2+no_single+no_static+python27 (active)
-Joseph
comment:42 follow-up: 43 Changed 10 years ago by xanda-escuyer (xanda)
Thanks for the solution - it worked a treat.
comment:43 follow-up: 44 Changed 10 years ago by udbraumann
Replying to xanda@…:
Thanks for the solution - it worked a treat.
Nice to read this, unfortunately I find not time to make a proposal for a modified Portfile. Another open point is that using gcc48 excludes any possibility to do universal binary building (but honestly, who is essentially in need of universal builds?). clang
would allow universal building, but presently clang
3.1 to 3.3 are not sufficiently working, and clang
3.4 cannot be built so far. As soon these building problems are being fixed in the near future (I hope!), I am looking forward if 3.4 is working for PPC, and in case it is, boost
possibly can be build again without my hack described above on PCCs.
comment:44 Changed 10 years ago by devernay (Frédéric Devernay)
Another option is disable the "log" library (add "--without-libraries=log" after "--without-libraries=coroutine" at two places in the Portfile), and use g++-4.2.
I was able to produce universal boost 1.55 that way (without the log library of course)
comment:45 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I was able to build boost 1.56 on Tiger and Leopard just by removing the gcc 4.2 blacklisting in r126002.
It also failed on the Snow Leopard buildbot; I'd expect it to also fail on Leopard and Tiger. It built fine on the Lion and Mountain Lion buildbots.