boost @1.54.0 fails to upgrade

[nonstop.server@…]

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

[ryandesign (Ryan Carsten Schmidt)]

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.

[cooljeanius (Eric Gallager)]

Cc Me!

[mkae (Marko Käning)]

Cc Me!

[gnw3]

Cc Me!

[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.

[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!

[mndavidoff (Monte Davidoff)]

Cc Me!

[nonstop.server@…]

Replying to gnwiii@…:

Thank you for your advice!
I was also able to upgrade boost successfully using compiler gcc 4.8.

[bitpup]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #39822.

[ryandesign (Ryan Carsten Schmidt)]

Using a MacPorts gcc compiler is not a viable solution. If no Xcode compiler is suitable, use clang 3.3.

[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?

[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.

[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).

[deesto (John S. De Stefano Jr.)]

Cc Me!

[jmroot (Joshua Root)]

r108421 r108422 r108424

[ci42]

Has duplicate #39837.

[deesto (John S. De Stefano Jr.)]

Fix in 1.54.0 confirmed for me on Snow Leopard. Thank you.

[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.

[jdgleeson]

Cc Me!

[udbraumann]

Cc Me!

[devernay (Frédéric Devernay)]

#39761 mentions llvm-3.3 linking problems on PPC, but this seems unrelated. The closest bug is still #39052, which would deserve being reopened.

[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

[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?

[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.

[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.

[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.

[jdgleeson]

using gcc48 after hack to remove -arch option

[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 {
    configure.args-append   --without-libraries=context,log
    compiler.blacklist-remove llvm-gcc-4.2 apple-gcc-4.2 gcc-4.2 gcc-4.0 apple-gcc-4.0 gcc-3.3
    compiler.fallback-remove macports-clang-3.3
}

[mklein-de (Michael Klein)]

Cc Me!

[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

[udbraumann]

using mp-clang-3.3

[udbraumann]

using mp-clang-3.3

[mdbecque@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicates #39870, #40385.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #41901.

[xanda-escuyer (xanda)]

Cc Me!

[xanda-escuyer (xanda)]

Cc Me!

[khepler]

Cc Me!

[potmj (Michael Pot)]

Cc Me! As a dependent, trying to install geda-gaf 10.5.8 Intel

[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.

[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

[dgonyier (Dwaine Gonyier)]

Cc Me!

[xanda-escuyer (xanda)]

Thanks for the solution - it worked a treat.

[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.

[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)

[ryandesign (Ryan Carsten Schmidt)]

I was able to build boost 1.56 on Tiger and Leopard just by removing the gcc 4.2 blacklisting in r126002.