This is for GCC 4.3 stabilisation. Please add arches as you see fit. Thanks.
My system is an HPPA Gentoo 2008.0 up to date with fresh portage tree and stable versions of everything but gcc. I did some tests, but I went with dev-util/boost-r2 since ChangeLog says it has specific patches for HPPA. gcc-4.2.4 emerges correctly boost-1.35.0-r2 - didn't run test suite (yet) gcc-4.3.2 does not emerge boost-1.35.0-r2 with optimized C[XX]FLAGS, -j3 in MAKEOPTS and FEATURES="test userpriv -usersandbox". It halts after some 27 hours with [1]. the same gcc-4.3.2 does not emerge boost-1.35.0-r2 with blank CFLAGS, CXXFLAGS, MAKEOPTS and FEATURES="-test". It hangs at [2] saying [3]. dev-util/boost-build-1.35.0-r1 (not -r2) builds correctly with both gcc-4.2.4 and 4.3.2 with optimized flags, parallel make, and tests enabled (and passing all of them). Will attach buildlogs and [quotes]. Hope this helps.
Created attachment 172251 [details] build.log for gcc-4.3.2 with tests [hppa, fail, 21MiB] [1] merge failed with: /var/tmp/portage/dev-libs/boost-1.35.0-r2/temp/environment: line 3083: /var/tmp/portage/dev-libs/boost-1.35.0-r2/work/boost_1_35_0/dist/ bin/process_jam_log: No such file or directory
Created attachment 172253 [details] build.log for gcc-4.3.2 safe flags and no tests [hppa, fail] [2] merge failed with: ...failed gcc.link.dll bin.v2/libs/wave/build/gcc-4.3/gentoorelease/libboost_wave.so... ...failed updating 1 target... ...updated 149 targets... [3] failed while executing: bjam ${NUMJOBS} -q ${OPTIONS} threading=single,multi link=shared,static runtime-link=shared,static --prefix="${D}/usr" --layout=system || die "building boost failed";
well, so hppa will have to lose boost support. This won't hold up a gcc-4.3 stabilization. sorry. Target Keywords: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86
Both stable on alpha.
Tests fail 6 hours in: testing.capture-output ../bin.v2/status/integer_traits_test.test/gcc-4.1/gentoorelease/integer_traits_test.run **passed** ../bin.v2/status/integer_traits_test.test/gcc-4.1/gentoorelease/integer_traits_test.test MkDir1 ../bin.v2/status/test_pool_alloc.test MkDir1 ../bin.v2/status/test_pool_alloc.test/gcc-4.1 MkDir1 ../bin.v2/status/test_pool_alloc.test/gcc-4.1/gentoorelease gcc.compile.c++ ../bin.v2/status/test_pool_alloc.test/gcc-4.1/gentoorelease/test_pool_alloc.o gcc.link ../bin.v2/status/test_pool_alloc.test/gcc-4.1/gentoorelease/test_pool_alloc testing.capture-output ../bin.v2/status/test_pool_alloc.test/gcc-4.1/gentoorelease/test_pool_alloc.run **passed** ../bin.v2/status/test_pool_alloc.test/gcc-4.1/gentoorelease/test_pool_alloc.test ...failed updating 31 targets... ...skipped 33 targets... ...updated 18012 targets... /var/tmp/paludis/dev-libs-boost-1.35.0-r1/temp/loadsaveenv: line 4446: /var/tmp/paludis/dev-libs-boost-1.35.0-r1/work/boost_1_35_0/dist/bin/process_jam_log: No such file or directory
Oops, forgot a little bit at the end: !!! ERROR in dev-libs/boost-1.35.0-r1: !!! In src_test at line 4448 !!! Postprocessing the build log failed
this is a blocker for gcc-4.3 stabilization on major arches.
(In reply to comment #8) > this is a blocker for gcc-4.3 stabilization on major arches. > Out of curiosity, why does a minor compiler revision bump (4.1 --> 4.3) require a revision bump of boost, anyway? What's wrong with boost-1.34.x? I might see it if this were gcc-4.x. --> gcc-5.x. (Yes, I know the minor gcc-4.1 --> gcc-4.3 seems to cause major pain, but it seems if gcc-4.3 can't handle earlier versions of boost, and boost-1.35.x causes us problems, upstream testing someplace has gone wrong. For what it's worth, boost-1.35.0-r1 does build on sparc, but I have not run it through its tests. I don't see that anyone else has, either, yet, except for alpha. I do see failures reported though.)
boost-1.35.0-r2 is failing for me on sparc with gcc-4.3.3. These are the errors: MkDir1 bin.v2/libs/graph MkDir1 bin.v2/libs/graph/build MkDir1 bin.v2/libs/graph/build/gcc-4.1 MkDir1 bin.v2/libs/graph/build/gcc-4.1/gentoorelease gcc.compile.c++ bin.v2/libs/date_time/build/gcc-4.1/gentoorelease/link-static/threading-multi/greg_month.o gcc.archive bin.v2/libs/date_time/build/gcc-4.1/gentoorelease/link-static/threading-multi/libboost_date_time-mt.a MkDir1 bin.v2/libs/graph/build/gcc-4.1/gentoorelease/link-static gcc.compile.c++ bin.v2/libs/date_time/build/gcc-4.1/gentoorelease/threading-multi/greg_month.o gcc.link.dll bin.v2/libs/date_time/build/gcc-4.1/gentoorelease/threading-multi/libboost_date_time-mt.so gcc.link.dll bin.v2/libs/wave/build/gcc-4.1/gentoorelease/threading-multi/libboost_wave-mt.so MkDir1 bin.v2/libs/graph/build/gcc-4.1/gentoorelease/link-static/runtime-link-static gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.1/gentoorelease/read_graphviz_spirit.o {standard input}: Assembler messages: {standard input}:34907: Warning: end of file not at end of a line; newline inserted sparc-unknown-linux-gnu-g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See <URL:http://bugs.gentoo.org/> for instructions. "sparc-unknown-linux-gnu-g++" -ftemplate-depth-128 -O2 -mcpu=ultrasparc -pipe -finline-functions -Wno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_GRAPH_DYN_LINK=1 -DBOOST_GRAPH_NO_LIB=1 -DNDEBUG -I"." -I"libs/graph/src" -c -o "bin.v2/libs/graph/build/gcc-4.1/gentoorelease/read_graphviz_spirit.o" "libs/graph/src/read_graphviz_spirit.cpp" ...failed gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.1/gentoorelease/read_graphviz_spirit.o... ...removing bin.v2/libs/graph/build/gcc-4.1/gentoorelease/read_graphviz_spirit.o ...skipped <pbin.v2/libs/graph/build/gcc-4.1/gentoorelease>libboost_graph.so for lack of <pbin.v2/libs/graph/build/gcc-4.1/gentoorelease>read_graphviz_spirit.o... gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.1/gentoorelease/link-static/read_graphviz_spirit.o gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.1/gentoorelease/link-static/runtime-link-static/read_graphviz_spirit.o ...failed updating 1 target... ...skipped 1 target... ...updated 688 targets...
I was able to get boost-1.35.0-r2 to merge on sparc with gcc-4.3.3. My problem was solved by the solution found in Bug 250824 (activating my swap partitions and setting MAKEOPTS=-j1 from -j3).
Created attachment 183023 [details] Log showing failure for wesnoth-1.4.7-r1 against boost-1.35.0-r1 boost-1.35.0-r1 cannot be used in the build of games-strategy/wesnoth-1.4.7-r1 (current stable version) on sparc, at least. Since wesnoth-1.4.7-r1 builds fine against boost-1.34.1-r2, this shows an incompatibility in -1.35.0-r1 which breaks current stable tree. Attached log shows the failure.
(In reply to comment #12) > Created an attachment (id=183023) [edit] > Log showing failure for wesnoth-1.4.7-r1 against boost-1.35.0-r1 > > boost-1.35.0-r1 cannot be used in the build of games-strategy/wesnoth-1.4.7-r1 > (current stable version) on sparc, at least. Since wesnoth-1.4.7-r1 builds > fine against boost-1.34.1-r2, this shows an incompatibility in -1.35.0-r1 which > breaks current stable tree. Attached log shows the failure. > The problem appears to be some conflict in the configure script for wesnoth and boost on sparc; it does not show up on amd64. The failing program is: ====================== #include <boost/iostreams/device/file_descriptor.hpp> int main () { boost::iostreams::file_descriptor fd(0); fd.close(); ; return 0; } ====================== And the errors are either: "cannot find <some strange library>" or "conftest.cpp:(.text+0x30): undefined reference to `__sync_fetch_and_add_4'" Now, if you compile this test by hand and load it with g++ -o con -L/usr/lib -lboost_iostreams-mt con.o that works fine with boost-1.34.1-r2. However, on sparc, this same program does fail to load with ============================g++ -o con -L/usr/lib -lboost_iostreams-mt con.c -lX11 -Wl,-O1 -W -Wall -ansi -O2 -mcpu=ultrasparc3 -pipe /tmp/.private/fmccor/ccMapV8B.o: In function `main': con.c:(.text+0x30): undefined reference to `__sync_fetch_and_add_4' con.c:(.text+0x5c): undefined reference to `__sync_fetch_and_add_4' con.c:(.text+0x98): undefined reference to `__sync_fetch_and_add_4' con.c:(.text+0xc4): undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status and examining the assembly code generated from the program shows the program does reference this: call __sync_fetch_and_add_4, 0 But with boost-1.34.1-r2, we get an entirely different code sequence which uses threads: It uses call pthread_mutex_lock, 0 ... call pthread_mutex_unlock, 0 So I expect that boost-1.35 is expecting something in glibc which is not present for sparc. NOTE: sparc is using sys-libs/glibc-2.6.1 amd64 is using sys-libs/glibc-2.8_p20080602-r1 So this might just be a library version problem.
gcc minor version bumps pretty much always break boost. eg gcc-4.4 broke boost-1.35.0. it's a fact of life. the issue you're having is bug #230529, which was fixed in -r2. i think we should be stabilizing that version instead.
yes, either that or try the p.masked slotted version instead which contains a couple of fixes more for hppa :-\
Tests still fail with -r2 on amd64 with the same problem as comment #6.
(In reply to comment #14) > gcc minor version bumps pretty much always break boost. eg gcc-4.4 broke > boost-1.35.0. it's a fact of life. > > the issue you're having is bug #230529, which was fixed in -r2. i think we > should be stabilizing that version instead. > dev-libs/boost-1.35.0-r2 can be used on sparc (back to mutex for synchronization) but -1.35.0-r1 is unusable. So certainly sparc will not mark -r1 stable. :) Thanks.
what's the holdup?
so i have 168 testsuite failures using gcc 4.3 and that really sucks. i'm not really sure what we should do here.
FWIW, the current stable (1.34.1-r2) has 19 test failures when built with gcc 4.1, but the ebuild doesn't die for some reason.
(In reply to comment #19) > so i have 168 testsuite failures using gcc 4.3 and that really sucks. i'm not > really sure what we should do here. > I would start with your einfos: "The tests may take several hours on a recent machine" "but they will not fail (unless something weird happens ;-)" "This is because the tests depend on the used compiler/-version" "and the platform and upstream says that this is normal." That is totally different issue than what Thomas Anderson sees.
okay, i've ported 1.34.1-r2 to gcc 4.3 and fixed the testsuite failures, so that part's taken care of. i'll work on getting 1.35.0 into better shape today.
Created attachment 186055 [details, diff] fix testsuite postprocessing this is what i applied. dev-zero, you'll probably want to fix -r3 and -r4 as well. okay, stabilize away.
amd64 stable
Marked ppc stable.
-r2 is good, sparc stable
alpha/ia64/x86 stable
x86 stable
ppc64 done
So...this is supposed to work fine with gcc-4.1?
arm/s390/sh stable
Won't go stable for HPPA because of bug #244834. Closing.