Even if I pass explicitly --enable-shared (this way the bootstrap completes), still something is wrong, in that I cannot run anymore 'make check' inside the libstdc++-v3 build dir (this worked fine 'til ~15 days ago): === libstdc++ tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /usr/src/paolo/gcc-head/gcc/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /usr/src/paolo/gcc-head/gcc/libstdc++-v3/testsuite/libstdc++-dg/normal.exp ... /abuild/paolo/gcc-head/gcc/xgcc: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory while executing "exec /abuild/paolo/gcc-head/gcc/xgcc --print-multi-directory" ("eval" body line 1) invoked from within ... ...
This is related to PR 17469 also.
A 3.4 regression also, really the patch which did libunwind for all ia64-linux even where libunwind did not exist before was a patch which should have been tested better.
A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00295.html
Postponed until GCC 3.4.4.
This is not critical according to the criteria.
Moving to 4.0.2 pre Mark.
Does this work now or do we still need the patch?
Sorry, I don't have available anymore systems not provided of libunwind...
This issue is not release-critical; marking as P5.
won't fix for GCC-4.0.x
Closing 4.1 branch.
This one is really old. HJ, do you know if this is still an issue? What happened with your patch?
(In reply to comment #12) > This one is really old. HJ, do you know if this is still an issue? What > happened with your patch? > I don't know. All my machines have libunwind.so.7.
Fixed as of gcc-4.2.x.