At an unstable Gentoo Linux image I get (both gcc-4.6.2 and 4.7.2) : ... testcond : SUCCESS testlfs : \/bin/bash: line 2: 5321 Segmentation fault (core dumped) ./$prog Programs failed: testall make[1]: *** [check] Error 139 make[1]: Leaving directory `/var/tmp/portage/dev-libs/apr-1.4.6/work/apr-1.4.6/test' ... and GDB says : ... Core was generated by `./testall'. Program terminated with signal 11, Segmentation fault. #0 apr_file_info_get (finfo=finfo@entry=0xbf990df4, wanted=wanted@entry=7582064, thefile=0x1) at file_io/unix/filestat.c:157 157 if (thefile->buffered) { (gdb) bt #0 apr_file_info_get (finfo=finfo@entry=0xbf990df4, wanted=wanted@entry=7582064, thefile=0x1) at file_io/unix/filestat.c:157 #1 0x0806a824 in test_reopen (tc=0xbf990e78, data=<optimized out>) at testlfs.c:120 #2 test_reopen (tc=0xbf990e78, data=0x0) at testlfs.c:108 #3 0x0804d998 in abts_run_test (ts=ts@entry=0x909c0c0, f=f@entry=0x806a790 <test_reopen>, value=value@entry=0x0) at abts.c:168 #4 0x0806ab7c in testlfs (suite=0x909c0c0) at testlfs.c:356 #5 0x0804d255 in main (argc=1, argv=0xbf990fa4) at abts.c:424
Can you check in the buildlog if the compiler defines are the same when compiling the library itself and when compiling the tests? Especially WRT -D_LARGEFILE64_SOURCE? Another issue could be if LD_LIBRARY_PATH is set and the tests somehow use a different libapr1.so than the one that has just been built. You could insert a line with "ldd ./$$prog; \" into test/Makefile before the ./$$prog call to see which library is used.
Created attachment 29797 [details] build log (In reply to comment #1) > Can you check in the buildlog if the compiler defines are the same when > compiling the library itself and when compiling the tests? Especially WRT > -D_LARGEFILE64_SOURCE? seems to be specified correctly always (pls seee attachedd build log) > Another issue could be if LD_LIBRARY_PATH is set and the tests somehow use a > different libapr1.so than the one that has just been built. You could insert > a line with "ldd ./$$prog; \" into test/Makefile before the ./$$prog call to > see which library is used. it points to the tmp file : libapr-1.so.0 => /var/tmp/portage/dev-libs/apr-1.4.6-r1/work/apr-1.4.6/.libs/libapr-1.so.0 (0xb7747000) (and nevertheless after the 2nd re-install even the sytem wide visible lib would be the same, isn't it ? What's interesting is that the test cases doesn't fail relyable, 2 subsequent call in a row show : n22 /var/tmp/portage/dev-libs/apr-1.4.6-r1/work/apr-1.4.6 # ./test/testall testatomic : SUCCESS testdir : FAILED 2 of 13 testdso : FAILED 8 of 9 testdup : SUCCESS testenv : SUCCESS testfile : FAILED 3 of 35 testfilecopy : FAILED 2 of 4 testfileinfo : SUCCESS testflock : FAILED 2 of 3 testfmt : SUCCESS testfnmatch : FAILED 2 of 4 testargs : SUCCESS testhash : SUCCESS testipsub : SUCCESS testlock : SUCCESS testcond : SUCCESS testlfs : SUCCESS testmmap : |Segmentation fault (core dumped) n22 /var/tmp/portage/dev-libs/apr-1.4.6-r1/work/apr-1.4.6 # ./test/testall testatomic : SUCCESS testdir : SUCCESS testdso : FAILED 8 of 9 testdup : SUCCESS testenv : SUCCESS testfile : SUCCESS testfilecopy : FAILED 2 of 4 testfileinfo : SUCCESS testflock : FAILED 2 of 3 testfmt : SUCCESS testfnmatch : FAILED 2 of 4 testargs : SUCCESS testhash : SUCCESS testipsub : SUCCESS testlock : SUCCESS testcond : SUCCESS testlfs : SUCCESS testmmap : |Segmentation fault (core dumped) (but since today I'm running glibc-2.17 for that chroot'ed test+play system) together with 3.7.1 as kernel.