Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests don't set rpath #21

Open
davidchisnall opened this issue Mar 21, 2018 · 3 comments
Open

Tests don't set rpath #21

davidchisnall opened this issue Mar 21, 2018 · 3 comments
Assignees

Comments

@davidchisnall
Copy link
Member

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.

@rfm
Copy link
Contributor

rfm commented Mar 21, 2018

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.

@davidchisnall
Copy link
Member Author

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.

@rfm
Copy link
Contributor

rfm commented Mar 21, 2018

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.

qmfrederik pushed a commit to qmfrederik/libs-base that referenced this issue Dec 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants