libs-base icon indicating copy to clipboard operation
libs-base copied to clipboard

Tests don't set rpath

Open davidchisnall opened this issue 7 years ago • 3 comments

The GNUstep Base test suite doesn't set the rpath to point to the built library. This means that you need to juggle LD_LIBRARY_PATH directives if you want to run the tests against the just-build -base, without having to install it.

davidchisnall avatar Mar 21 '18 08:03 davidchisnall

Doing 'make check' for base already runs the base testsuite on the uninstalled library, which is usually what you want. So what is the nature of the issue/problem? Is it that you want testcases, once built, to be executable directly/externally and still use the uninstalled library without having to reproduce the LD_LIBRARY_PATH 'magic' that the test suite does for you when you run the tests normally? Or is it that you want to have gnustep-tests, when run for the base testsuite, think it should build and run the tests using the library in ../../Source/obj and headers in ../../Headers if they exist?

I looked up -rpath online and found that the order of precedence for library search is:

  1. LD_LIBRARY_PATH
  2. -rpath
  3. system default paths

I added a couple of lines to build the testcases with -rpath as it seems harmless, but I'm not at all sure it actually resolves either of those two issues most of the time since LD_LIBRARY_PATH takes precedence, though it clearly fixes them in the case you are building/testing a library for the first time (ie there is no installed version).

So if you run testcases using gnustep-tests or even directly in a gnustep environment, I expect the LD_LIBRARY_PATH will cause the installed version to be used (if it exists), but the uninstalled version (pointed to by -rpath) to be used otherwise.

On the other hand, if you run them using 'make check' the normal code to set LD_LIBRARY_PATH to point to the uninstalled library for the duration of the tests will still be used.

rfm avatar Mar 21 '18 13:03 rfm

Doing 'make check' for base already runs the base testsuite on the uninstalled library, which is usually what you want.

Does it? I encountered this problem running make check and having everything fail.

Is it that you want testcases, once built, to be executable directly/externally and still use the uninstalled library without having to reproduce the LD_LIBRARY_PATH 'magic' that the test suite does for you when you run the tests normally?

This is pretty much a minimum if I'm trying to debug a failing test, yes.

davidchisnall avatar Mar 21 '18 13:03 davidchisnall

Does it? Yes ... try 'make messages=yes check' to see how it's setting up the environment.

eg.

$ cd Tests [richard@centos-linux Tests]$ make check This is gnustep-make 2.7.0. Type 'gmake print-gnustep-make-help' for help. Running in gnustep-make version 2 strict mode. (
GNUSTEP_LOCAL_ADDITIONAL_MAKEFILES="/home/richard/git/libs-base/base.make";
ADDITIONAL_INCLUDE_DIRS="-I/home/richard/git/libs-base/Headers -I/home/richard/git/libs-base/Source/.";
ADDITIONAL_LIB_DIRS="-L/home/richard/git/libs-base/Source/./obj";
ADDITIONAL_LDFLAGS="-Wl,-rpath,/home/richard/git/libs-base/Source/./obj";
LD_LIBRARY_PATH="/home/richard/git/libs-base/Source/./obj:/home/richard/GNUstep/Library/Libraries:/home/richard/gnustep-ng/Local/Library/Libraries:/home/richard/gnustep-ng/System/Library/Libraries";
PATH="/home/richard/git/libs-base/Tools/./obj:/home/richard/GNUstep/Tools:/home/richard/gnustep-ng/Local/Tools:/home/richard/gnustep-ng/System/Tools:/usr/lib64/qt-3.3/bin:/home/richard/perl5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/richard/bin";
export GNUSTEP_LOCAL_ADDITIONAL_MAKEFILES;
export ADDITIONAL_INCLUDE_DIRS;
export ADDITIONAL_LDFLAGS;
export ADDITIONAL_LIB_DIRS;
export LD_LIBRARY_PATH;
export PATH;
if [ "" = "" ]; then
gnustep-tests base;
else
gnustep-tests --debug base;
fi;
) --- Running tests in base --- --- Running tests in base/coding --- --- Running tests in base/Functions --- ...

I encountered this problem running make check and having everything fail. Then it would be good to know what made it fail, so it could be dealt with. I use this on an almost daily basis.

This is pretty much a minimum if I'm trying to debug a failing test, yes. I'm used to having my LD_LIBRARY_PATH set up by scripts for each different environment I'm working in, but I can see how, if you don't automate that sort of thing, it could be a pain.

One option if you don't want to alter your normal shell is to put the LD_LIBRARY_PATH setup into TestInfo for the directory your testcases are in, then you can use gnustep-tests --debug to debug any failing testcases. gnustep-make does something similar for libraries and frameworks using the foo_TEST_DIR option to integrate regression tests for the library/framework named 'foo'. In this case 'make check' generates a 'make-check.env' file which provides the environment for gnustep-tests to run testcases in.

rfm avatar Mar 21 '18 14:03 rfm