gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GnuCOBOL-users] modfying how tests are built


From: Brian Tiffin
Subject: Re: [GnuCOBOL-users] modfying how tests are built
Date: Thu, 21 Feb 2019 18:35:44 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]