James K. Lowden wrote: > I would like to rebuild > > tests/testsuite.dir/0629 > > with --save-temps on, so that I can debug into the C file to understand > why I'm seeing a segfault in the trace facility. > > How do I do that? If the automatic test system is documented, I missed > it, for sure. > > Also, I want to report the tests are linked to the installed library, > not the libcob.so that's in the build tree: > > $ pwd && ldd ./prog | grep libcob > [...]/build/tests/testsuite.dir/0629 > libcob.so.4 => /usr/local/lib/libcob.so.4 (0x00007f816ed2c000) > > That's less than ideal. Anyone running "make check" that way before > installing is getting a false positive/negative. (Actually, per above, > the tests should fail to link if the version has changed.) > > My workaround has been to use LD_PRELOAD to force use of the in-tree > library. The solution would seem to be to either do that automatically > during the running of tests (which might be done; I don't know) or to > set the RPATH to use the in-tree library. > > --jkl > I haven't done this in a while, but on failure, in tests/testsuite.dir/nnn/ there will be a prog.cob (usually prog.cob, there may be others for the test at hand). You can drag that out to a working dir, and run cobc -xg prog.cob to get a gdb friendlier compile. -g saves the various generated files in the current working dir so that gdb can find sources. That is complicated by a pre-installed compiler build, but from the shell in the working dir, you can source . [extractdir]/tests/atconfig . [extractdir]/tests/atlocal This should setup the environment for clean links to the pre-installed build tree. (If not, there may be bugs to hunt down in the autoconf scripts). And you are right, the behaviour you listed in less than ideal. Hopefully the above out-of-tree build trick will help. Note that that shell now has a whack load of non-normal environment settings, and you do not want to use that same shell for other work. Clean up by exiting and starting a new shell. For sourcing the two autotest scripts above, you can create an ease of use shell function to do the same; and it'll set up the environment in the current parent shell, and not just fork out a new shell that exits and forgets the settings. There has been recent discussions over the last few days in the GNU developer mailing lists focused on this very topic for all uninstalled GNU packages in test; smarter people are on the case and working the problem. Results should be making the rounds very soon and we'll strive to follow along with the suggested best practices. Hope that offers some clues to help you proceed, James. Have good, Brian
