| Summary: | Please stabilise dev-libs/boost-1.35.0-r2 and dev-util/boost-build 1.35.0-r1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christian Faulhammer (RETIRED) <fauli> |
| Component: | New packages | Assignee: | C++ Team [disbanded] <cpp+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | dev-zero, esigra, giles, luckyluke, nikoli, please.no.spam.here, rhill, xenoterracide |
| Priority: | Highest | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 244834 | ||
| Bug Blocks: | 236113, 245160, 264121 | ||
| Attachments: |
build.log for gcc-4.3.2 with tests [hppa, fail, 21MiB]
build.log for gcc-4.3.2 safe flags and no tests [hppa, fail] Log showing failure for wesnoth-1.4.7-r1 against boost-1.35.0-r1 fix testsuite postprocessing |
||
|
Description
Christian Faulhammer (RETIRED)
2008-11-01 20:38:20 UTC
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. |
