gfortran and libgomp tests do not link the just-built libraries when "make check" is run unless the libraries are first installed in $prefix/lib. This results in the following differences in the reported error rate for gfortran: Testing after running make install: < # of expected passes 14014 < # of unexpected failures 33 Testing without running make install: > # of expected passes 13143 > # of unexpected failures 824 For libgomp: Testing after running make install: < # of expected passes 1075 < # of unexpected failures 205 Testing without running make install: > # of expected passes 963 > # of unexpected failures 317 The results after make install, with two patches installed, can be found at http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01383.html
I don't have this issue on any target that I test on, which includes x86_64-linux-gnu and i686-linux-gnu and powerpc64-linux-gnu and yes I do testing of -m64/-m32 on both powerpc64-linux-gnu and x86_64-linux-gnu.
I noticed this issue tonight while doing a make check on a build of powerpc64-apple-darwin8 in the libgomp testsuite. A typical set of failures include... FAIL: libgomp.c++/ctor-1.C -O0 (test for excess errors) FAIL: libgomp.c++/ctor-1.C -O1 (test for excess errors) FAIL: libgomp.c++/ctor-1.C -O2 (test for excess errors) FAIL: libgomp.c++/ctor-1.C -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.c++/ctor-1.C -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.c++/ctor-1.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.c++/ctor-1.C -O3 -g (test for excess errors) FAIL: libgomp.c++/ctor-1.C -Os (test for excess errors) which in the libgomp.log show a typical failure of... set_ld_library_path_env_vars: ld_library_path=.:/Users/howarth/darwin_obj/powerpc64-apple-darwin8/./libgomp/.libs:/Users/howarth/darwin_obj/powerpc64-apple-darwin8/./libgomp/../libstdc++-v3/src/.libs:/Users/howarth/darwin_obj/gcc Executing on host: /Users/howarth/darwin_obj/gcc/xgcc -B/Users/howarth/darwin_obj/gcc/ /Users/howarth/gcc/libgomp/testsuite/libgomp.c++/ctor-1.C -B/Users/howarth/darwin_obj/powerpc64-apple- darwin8/./libgomp/ -I/Users/howarth/darwin_obj/powerpc64-apple-darwin8/./libgomp -I/Users/howarth/gcc/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O0 -L/Users/howarth/darwin_obj/po werpc64-apple-darwin8/./libgomp/.libs -lgomp -L/Users/howarth/darwin_obj/powerpc64-apple-darwin8/./libgomp/../libstdc++-v3/src/.libs -lstdc++ -lm -m64 -o ./ctor-1.exe (timeout = 300) ld64 warning: indirect library /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib could not be loaded: file not found: /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib ld64 warning: indirect library /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib could not be loaded: file not found: /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib output is: ld64 warning: indirect library /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib could not be loaded: file not found: /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib ld64 warning: indirect library /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib could not be loaded: file not found: /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib FAIL: libgomp.c++/ctor-1.C -O0 (test for excess errors) Excess errors: ld64 warning: indirect library /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib could not be loaded: file not found: /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib ld64 warning: indirect library /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib could not be loaded: file not found: /Users/howarth/work/gcc42/lib/libgcc_s.1.dylib when the build isn't installed before the make check is run.
I think I know what's going on. Libraries contain an install name when built, this is what it put into the file that is linked against the library. The problem is, the install name isn't correct, until the file is installed. So, one solution, would be to build the library with the build tree name, and then during install, change the name. I wonder what libstdc++ is doing. I do wonder why it works better in 32-bit mode? I wonder if have 64-bit: $ file /usr/lib/libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib: Mach-O universal binary with 4 architectures /usr/lib/libgcc_s.1.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/lib/libgcc_s.1.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /usr/lib/libgcc_s.1.dylib (for architecture ppc): Mach-O dynamically linked shared library ppc /usr/lib/libgcc_s.1.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64 I wonder, if you try building these with --shared-libgcc, does it then work?
I suspect this is a darwin only bug.
I believe the bug exists just the same in the 32-bit mode build. The only reason I saw it at 64-bit was that I hadn't installed the build first. Normally I test from builds for fink packaging so the previous build is always installed.
I haven't seen that one in years. Indeed, I just did a clean rebuild, removed all my previously installed stuff, and can confirm libgomp and gfortran test suites run fine.