Hi Everyone/Niels,
I've got a bare-bones Mac-mini without Xcode. It has CC Tools but that is it. It is in a stock configuration.
When I attempt to run 'make check' nearly every test failed due to missing libnettle and libhogweed. The libraries were present in .lib/, but something was blowing away LD_LIBRARY_PATH and DYLD_LIBRARY_PATH. My driver script set it, and the Nettle sources also set it after I set it. But by the times the test runner scripts were run, they were empty again (they were empty at the Makefile, before hitting the test runners).
I know Apple did some hardening lately but I have not read anything about scrubbing LD_LIBRARY_PATH and DYLD_LIBRARY_PATH. But it appears something was sanitizing the environment.
Attached is the patch I needed for the issue on OS X 10.12. It also tested good on Ubuntu 18.04 and Solaris 11.3. Earlier versions of OS X, like OS X 10.9 and OS X 10.5, were OK. It was just OS X 10.12.
The short of it is, each test runner, like run-tests.sh, needed to restore the variables using an absolute path. dirname is Posix so it is available to strip the unwanted path component, like testsuite/ or example/.
+nettle_lib_dir=`dirname $PWD`/.lib +LD_LIBRARY_PATH=$nettle_lib_dir +DYLD_LIBRARY_PATH=$nettle_lib_dir + +export LD_LIBRARY_PATH +export DYLD_LIBRARY_PATH
Jeff
Hi Jeff,
On Sat, Mar 28, 2020 at 01:52:05AM -0400, Jeffrey Walton wrote:
I know Apple did some hardening lately but I have not read anything about scrubbing LD_LIBRARY_PATH and DYLD_LIBRARY_PATH. But it appears something was sanitizing the environment.
In a quick test on Mojave it appears that any attempt to setenv() a variable that starts with DYLD_ is silently ignored. Can you confirm that? My testcase is:
DYLD_FOO=foo DLYD_FOO=bar bash -c 'echo $DYLD_FOO $DLYD_FOO'
from which I get only 'bar' and no 'foo'.
The short of it is, each test runner, like run-tests.sh, needed to restore the variables using an absolute path. dirname is Posix so it is available to strip the unwanted path component, like testsuite/ or example/.
+nettle_lib_dir=`dirname $PWD`/.lib +LD_LIBRARY_PATH=$nettle_lib_dir +DYLD_LIBRARY_PATH=$nettle_lib_dir
+export LD_LIBRARY_PATH +export DYLD_LIBRARY_PATH
I recently ran into a similar problem where uClibc on Linux by default ignores relative paths in LD_LIBRARY_PATH causing the same problems when running the test suite. So there's two reasons to think about alternatives to setting the variable.
Is the testsuite supposed to be relocatable or installable? If not, we could link with something like -Wl,-rpath,$(dir $(shell pwd))/.lib to avoid this issue (until Apple or uClibc hardens some more ;). I see that configure already checks and sets RPATHFLAG (seems unused though!?), so we could reuse that to try and avoid other fallout.
Michael Weiser michael.weiser@gmx.de writes:
In a quick test on Mojave it appears that any attempt to setenv() a variable that starts with DYLD_ is silently ignored. Can you confirm that? My testcase is:
DYLD_FOO=foo DLYD_FOO=bar bash -c 'echo $DYLD_FOO $DLYD_FOO'
from which I get only 'bar' and no 'foo'.
Odd. I hope it's still possible to set DYLD_LIBRARY_PATH to a valid absolute name of a directory?
I recently ran into a similar problem where uClibc on Linux by default ignores relative paths in LD_LIBRARY_PATH causing the same problems when running the test suite. So there's two reasons to think about alternatives to setting the variable.
I think a reasonable way is to add
abs_top_builddir = @abs_top_builddir@
TEST_SHLIB_DIR = "${abs_top_builddir}/.lib"
to config.make.in, and use that to set LD_LIBRARY_PATH. And possibly only pass TEST_SHLIB_DIR to the run-tests script, and move the logic to setup the environment.
Is the testsuite supposed to be relocatable or installable?
Not the test programs, but the programs in tools/ are, and they're also run by the testsuite.
If not, we could link with something like -Wl,-rpath,$(dir $(shell pwd))/.lib to avoid this issue (until Apple or uClibc hardens some more ;). I see that configure already checks and sets RPATHFLAG (seems unused though!?), so we could reuse that to try and avoid other fallout.
It's used by LSH_RPATH_FIX, just after the check for gmp.
: # Checks for libraries : if test "x$enable_public_key" = "xyes" ; then : if test "x$enable_mini_gmp" = "xno" ; then : AC_CHECK_LIB(gmp, __gmpn_sec_div_r,, : [AC_MSG_WARN( : [GNU MP not found, or too old. GMP-6.0 or later is needed, see : https://gmplib.org/. : Support for public key algorithms will be unavailable.])] : enable_public_key=no) : : # Add -R flags needed to run programs linked with gmp : LSH_RPATH_FIX : fi : fi
This is intended to handle the case that gmp is in /usr/local, you configure with --with-lib-path=/usr/local/lib --with-inlcude-path=/usr/local/include, but the runtime linker doesn't look in /usr/local/lib. Then LSH_RPATH_FIX will add the appropriate flag to set rpath. (I see there are some other unused macros in aclocal.m4, left overs from when nettle was taken out of lsh).
Regards, /Niels
Hello Niels,
On Tue, Mar 31, 2020 at 09:27:02AM +0200, Niels Möller wrote:
In a quick test on Mojave it appears that any attempt to setenv() a variable that starts with DYLD_ is silently ignored. Can you confirm that? My testcase is:
DYLD_FOO=foo DLYD_FOO=bar bash -c 'echo $DYLD_FOO $DLYD_FOO'
from which I get only 'bar' and no 'foo'.
Odd. I hope it's still possible to set DYLD_LIBRARY_PATH to a valid absolute name of a directory?
No, unfortunately it's not. Any attempt to set an environment variable whose name starts with DYLD_ seems to be ignored. It doesn't matter if you're a normal, admin or the root user either. It appears to be caused by SIP (System Integrity Protection):
https://github.com/nasa/europa/issues/181
And indeed on another system where I have SIP disabled, exporting DYLD_-variables works as expected with above test case. dyld even prints a warning that it doesn't know variable DYLD_FOO.
On Tue, Mar 31, 2020 at 5:45 AM Michael Weiser michael.weiser@gmx.de wrote:
On Tue, Mar 31, 2020 at 09:27:02AM +0200, Niels Möller wrote:
In a quick test on Mojave it appears that any attempt to setenv() a variable that starts with DYLD_ is silently ignored. Can you confirm that? My testcase is:
DYLD_FOO=foo DLYD_FOO=bar bash -c 'echo $DYLD_FOO $DLYD_FOO'
from which I get only 'bar' and no 'foo'.
Odd. I hope it's still possible to set DYLD_LIBRARY_PATH to a valid absolute name of a directory?
No, unfortunately it's not. Any attempt to set an environment variable whose name starts with DYLD_ seems to be ignored. It doesn't matter if you're a normal, admin or the root user either. It appears to be caused by SIP (System Integrity Protection):
SIP came to mind for me, too. I know SIP forbids installation in directories other then /usr/local. But I could not find reading that said it scrubbed the environmental variables.
I think Nettle's best choice is to set the variable in its test runner scripts, like run-tests.sh. We know things work when set from there.
Jeff
Hi Jeff,
On Tue, Mar 31, 2020 at 05:51:38AM -0400, Jeffrey Walton wrote:
In a quick test on Mojave it appears that any attempt to setenv() a variable that starts with DYLD_ is silently ignored. Can you confirm
Odd. I hope it's still possible to set DYLD_LIBRARY_PATH to a valid absolute name of a directory?
No, unfortunately it's not. Any attempt to set an environment variable whose name starts with DYLD_ seems to be ignored. It doesn't matter if you're a normal, admin or the root user either. It appears to be caused by SIP (System Integrity Protection):
I think Nettle's best choice is to set the variable in its test runner scripts, like run-tests.sh. We know things work when set from there.
Looking at your original mail I'm now struggling to see how exporting DYLD_LIBRARY_PATH closer to the test execution solves the issue. In my quick tests, exporting the variable is always ignored, no matter where and also in shell scripts.
(BTW: Apart from the code lines in your mail there was no patch attached to your mail. Was that intentional?)
I'm currently downloading Xcode and command line devel tools for Mojave to be able to test directly on the SIP-enabled box.
The github issue I referenced has a pretty comprehensive list of options (https://github.com/nasa/europa/issues/181#issuecomment-496614956):
1. Disable SIP as @theronic suggests. 2. Set DYLD_LIBRARY_PATH in main via setenv() 3. Link statically 4. Use otool to fix up the paths
(1. being a practical no-go) (2. not being an option for the tests because they already need to have found, loaded and linked the correct libnettle when their main is invoked. I think this would only work with dlopen().)
I already added: 5. Link with runtime path.
What also comes to mind is: 6. Link with @origin or @executable relative paths. That's something ELF can do also.
Seems a lot of effort just for the test suite though.
On Tue, Mar 31, 2020 at 6:30 AM Michael Weiser michael.weiser@gmx.de wrote:
On Tue, Mar 31, 2020 at 05:51:38AM -0400, Jeffrey Walton wrote:
In a quick test on Mojave it appears that any attempt to setenv() a variable that starts with DYLD_ is silently ignored. Can you confirm
Odd. I hope it's still possible to set DYLD_LIBRARY_PATH to a valid absolute name of a directory?
No, unfortunately it's not. Any attempt to set an environment variable whose name starts with DYLD_ seems to be ignored. It doesn't matter if you're a normal, admin or the root user either. It appears to be caused by SIP (System Integrity Protection):
I think Nettle's best choice is to set the variable in its test runner scripts, like run-tests.sh. We know things work when set from there.
Looking at your original mail I'm now struggling to see how exporting DYLD_LIBRARY_PATH closer to the test execution solves the issue. In my quick tests, exporting the variable is always ignored, no matter where and also in shell scripts.
Here's another example: https://apple.stackexchange.com/questions/286315/system-integrity-protection...
Apparently /bin/sh and /usr/bin/env are SIP protected, so they get some of their variables scrubbed.
I believe the reason the patch works is, the environment is scrubbed before run-tests.sh is run. run-tests.sh then sets DYLD_LIBRARY_PATH (and friends). Since the test runner is calling programs outside the SIP boundary, the variables persist.
(BTW: Apart from the code lines in your mail there was no patch attached to your mail. Was that intentional?)
My bad... I thought it was attached.
Here is the patch online: https://github.com/noloader/Build-Scripts/blob/master/patch/nettle.patch . Ignore the xts.c and ctr.c parts. They are hacks to work around another issue on older 32-bit machines.
I'm currently downloading Xcode and command line devel tools for Mojave to be able to test directly on the SIP-enabled box.
The github issue I referenced has a pretty comprehensive list of options (https://github.com/nasa/europa/issues/181#issuecomment-496614956):
- Disable SIP as @theronic suggests.
- Set DYLD_LIBRARY_PATH in main via setenv()
- Link statically
- Use otool to fix up the paths
(1. being a practical no-go) (2. not being an option for the tests because they already need to have found, loaded and linked the correct libnettle when their main is invoked. I think this would only work with dlopen().)
I already added: 5. Link with runtime path.
What also comes to mind is: 6. Link with @origin or @executable relative paths. That's something ELF can do also.
Seems a lot of effort just for the test suite though.
(2) may work, but it is not needed (based on my experience). Just set LD_LIBRARY_PATH and DYLD_LIBRARY_PATH in the test runner.
It may be worth mentioning that once Nettle is installed into /usr/local, then everything is OK. The thorny part is 'make check' before install. The test runners need <nettle dir>/.lib on-path to find the new libraries before install.
And if you already have Nettle installed, then you probably won't encounter the issue because the system will find the *.dylibs in /usr/local instead of using the ones at <nettle dir>/.lib.
Jeff
On Tue, Mar 31, 2020 at 6:44 AM Jeffrey Walton noloader@gmail.com wrote:
On Tue, Mar 31, 2020 at 6:30 AM Michael Weiser michael.weiser@gmx.de wrote:
On Tue, Mar 31, 2020 at 05:51:38AM -0400, Jeffrey Walton wrote:
In a quick test on Mojave it appears that any attempt to setenv() a variable that starts with DYLD_ is silently ignored. Can you confirm
Odd. I hope it's still possible to set DYLD_LIBRARY_PATH to a valid absolute name of a directory?
No, unfortunately it's not. Any attempt to set an environment variable whose name starts with DYLD_ seems to be ignored. It doesn't matter if you're a normal, admin or the root user either. It appears to be caused by SIP (System Integrity Protection):
I think Nettle's best choice is to set the variable in its test runner scripts, like run-tests.sh. We know things work when set from there.
Looking at your original mail I'm now struggling to see how exporting DYLD_LIBRARY_PATH closer to the test execution solves the issue. In my quick tests, exporting the variable is always ignored, no matter where and also in shell scripts.
Here's another example: https://apple.stackexchange.com/questions/286315/system-integrity-protection...
Apparently /bin/sh and /usr/bin/env are SIP protected, so they get some of their variables scrubbed.
I believe the reason the patch works is, the environment is scrubbed before run-tests.sh is run. run-tests.sh then sets DYLD_LIBRARY_PATH (and friends). Since the test runner is calling programs outside the SIP boundary, the variables persist.
(BTW: Apart from the code lines in your mail there was no patch attached to your mail. Was that intentional?)
My bad... I thought it was attached.
Here is the patch online: https://github.com/noloader/Build-Scripts/blob/master/patch/nettle.patch . Ignore the xts.c and ctr.c parts. They are hacks to work around another issue on older 32-bit machines.
I'm currently downloading Xcode and command line devel tools for Mojave to be able to test directly on the SIP-enabled box.
The github issue I referenced has a pretty comprehensive list of options (https://github.com/nasa/europa/issues/181#issuecomment-496614956):
- Disable SIP as @theronic suggests.
- Set DYLD_LIBRARY_PATH in main via setenv()
- Link statically
- Use otool to fix up the paths
(1. being a practical no-go) (2. not being an option for the tests because they already need to have found, loaded and linked the correct libnettle when their main is invoked. I think this would only work with dlopen().)
I already added: 5. Link with runtime path.
What also comes to mind is: 6. Link with @origin or @executable relative paths. That's something ELF can do also.
Seems a lot of effort just for the test suite though.
(2) may work, but it is not needed (based on my experience). Just set LD_LIBRARY_PATH and DYLD_LIBRARY_PATH in the test runner.
It may be worth mentioning that once Nettle is installed into /usr/local, then everything is OK. The thorny part is 'make check' before install. The test runners need <nettle dir>/.lib on-path to find the new libraries before install.
And if you already have Nettle installed, then you probably won't encounter the issue because the system will find the *.dylibs in /usr/local instead of using the ones at <nettle dir>/.lib.
I forgot to mention... DYLD_FALLBACK_LIBRARY_PATH may work. Apple used to have a man page on it, but I can't find it anymore.
The man page used to say, don't use DYLD_LIBRARY_PATH . Instead, use DYLD_FALLBACK_LIBRARY_PATH . The problem is, the fallback path is checked after other paths (iirc). That means an old Nettle in /usr/local might be loaded instead of the new Nettle in .lib/
Jeff
Hi Jeff,
On Tue, Mar 31, 2020 at 06:51:37AM -0400, Jeffrey Walton wrote:
I believe the reason the patch works is, the environment is scrubbed before run-tests.sh is run. run-tests.sh then sets DYLD_LIBRARY_PATH (and friends). Since the test runner is calling programs outside the SIP boundary, the variables persist.
I verified as much by copying /bin/bash to ~/bash and running it from there. Indeed, exported DYLD-variables propagate to ~/bash.
- Disable SIP as @theronic suggests.
- Set DYLD_LIBRARY_PATH in main via setenv()
- Link statically
- Use otool to fix up the paths
- Link with runtime path.
- Link with @origin or @executable relative paths.
(2) may work, but it is not needed (based on my experience). Just set LD_LIBRARY_PATH and DYLD_LIBRARY_PATH in the test runner.
I forgot to mention... DYLD_FALLBACK_LIBRARY_PATH may work. Apple used to have a man page on it, but I can't find it anymore.
It's in dyld(1).
The man page used to say, don't use DYLD_LIBRARY_PATH . Instead, use DYLD_FALLBACK_LIBRARY_PATH . The problem is, the fallback path is checked after other paths (iirc). That means an old Nettle in /usr/local might be loaded instead of the new Nettle in .lib/
Indeed, DYLD_FALLBACK_LIBRARY_PATH is not stripped but will also not prevent an already installed libnettle from being used for the tests.
nisse@lysator.liu.se (Niels Möller) writes:
I think a reasonable way is to add
abs_top_builddir = @abs_top_builddir@
TEST_SHLIB_DIR = "${abs_top_builddir}/.lib"
to config.make.in, and use that to set LD_LIBRARY_PATH. And possibly only pass TEST_SHLIB_DIR to the run-tests script, and move the logic to setup the environment.
I've pushed a change like that to the branch test-shlib-dir. Please try it out.
This also makes tests with a shared-library build work in termux on my android phone. It used to fail, in part because termux depends on LD_LIBRARY_PATH being set, and possibly with additional trouble from using an LD_LIBRARY_PATH with relative file names.
Regards, /Niels
On Tue, Mar 31, 2020 at 2:08 PM Niels Möller nisse@lysator.liu.se wrote:
nisse@lysator.liu.se (Niels Möller) writes:
I think a reasonable way is to add
abs_top_builddir = @abs_top_builddir@
TEST_SHLIB_DIR = "${abs_top_builddir}/.lib"
to config.make.in, and use that to set LD_LIBRARY_PATH. And possibly only pass TEST_SHLIB_DIR to the run-tests script, and move the logic to setup the environment.
I've pushed a change like that to the branch test-shlib-dir. Please try it out.
This also makes tests with a shared-library build work in termux on my android phone. It used to fail, in part because termux depends on LD_LIBRARY_PATH being set, and possibly with additional trouble from using an LD_LIBRARY_PATH with relative file names.
Tested mostly OK on my mac-mini:
... PASS: gostdsa-sign PASS: gostdsa-verify PASS: gostdsa-keygen PASS: cxx dyld: Library not loaded: /Users/jwalton/tmp/nettle/lib/libnettle.7.dylib Referenced from: /Users/jwalton/Build-Scripts/nettle-master/testsuite/../tools/sexp-conv Reason: image not found cmp: EOF on test1.out FAIL: sexp-conv dyld: Library not loaded: /Users/jwalton/tmp/nettle/lib/libhogweed.5.dylib Referenced from: /Users/jwalton/Build-Scripts/nettle-master/testsuite/../tools/pkcs1-conv Reason: image not found ./pkcs1-conv-test: line 26: 88645 Abort trap: 6 $EMULATOR ../tools/pkcs1-conv > testkey.priv <<EOF -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQC3792bBgQ/mc8aYOFaLEJES/JipmLAeVgznob/Vrzvdcx+bl6L 6gTphctU9ToOLC049dZYW3DJ53owUmbQgqB0vvLTjM9lGSEw4oXLrp7x/XVo/fZM UcRWq5H8Z0l6KANXHwcVcsjjqPBJ6WD/Is3o9rb58GU9GZcsMO2Zoh8z6wIDAQAB AoGABP+iwRS/xs6yPyBE34N2ZY6+zomBA4QIrpZvSr8bsVI9NW5gaWL5sTLunKdx ZXMz42li4tHRVdtRicCjhKUYIShH6J3ACKnBsCHwK6MgEyuDifxhmVt/b5xQNdOL bckwBXCL/XwkIkSgrvgUk/cXcvDXSdf7cRX+tgEHlbGjWGkCQQDaS9Xm3ZTIJ1CO /chlET2Cf/e5GzC79njzeg5oDyTG7qlXZudpZv5D6NatVoIDF4gfey6NKB7DNehT ff+v9wztAkEA17TN+cuFBuZX+KT3K7J1uavGqWOypDUy/h7PINODJLzoWAWnw94H NSu6/pXo1Q1WBMQa1jB1qxJaLpBp56iBNwJAUp6JIouSl/5pOvVKNxZDVXThaSml VD6AoIX9ldzFapVBelb0FqxoZ4NkXM50/n6VgnS4tawNmIx6lb8GWq8CMQJBAM5S lMofzyggX3jnYbycQFrOYYFYaWEDubi0A27koYYcYyj+j8+bqc1D/OLSxRg0X1jD st+5DnQJY9UyMPpyhNUCQQChMjCAamJP3xC7bOoza//k7E9kvx5IZcEsQWqok5BO PSVKy/gGBeN1Q7Rj+XoybQ/SqLpfgTYRI9UpbKmpkNuq -----END RSA PRIVATE KEY----- EOF
FAIL: pkcs1-conv dyld: Library not loaded: /Users/jwalton/tmp/nettle/lib/libnettle.7.dylib Referenced from: /Users/jwalton/Build-Scripts/nettle-master/testsuite/../tools/nettle-pbkdf2 Reason: image not found cmp: EOF on test1.out FAIL: nettle-pbkdf2 PASS: symbols PASS: dlopen ===================== 3 of 107 tests failed ===================== make[1]: *** [check] Error 1 make: *** [check] Error 2
Jeff
Jeffrey Walton noloader@gmail.com writes:
Tested mostly OK on my mac-mini:
Thanks for testing.
dyld: Library not loaded: /Users/jwalton/tmp/nettle/lib/libnettle.7.dylib
Is this the expected location after install, from
-install_name ${libdir}/$(LIBNETTLE_SONAME)
on the command linking libnettle.dylib?
Then maybe using DYLD_FALLBACK_LIBRARY_PATH could work a bit better, if the runtime linker only looks for libnettle.7.dylib in the given install location, and not in system directories. Will still not be correct if you install into a location where you have an older version but with the same soname, but at least will be correct in some more cases?
Referenced from: /Users/jwalton/Build-Scripts/nettle-master/testsuite/../tools/sexp-conv Reason: image not found cmp: EOF on test1.out FAIL: sexp-conv FAIL: pkcs1-conv FAIL: nettle-pbkdf2
The three failing tests are /bin/sh scripts running the binaries in tools/. I guess those still have DYLD_LIBRARY_PATH dropped from the environment, can you confirm?
To me, "system integrity protection", dropping DYLD_LIBRARY_PATH, seems a bit pointless in a setting where we're running code of our choice anyway.
Do you see any clean workaround? One could maybe delegate it further, similar to how $EMULATOR is handled.
Otherwise, we may just have to recommend disabling this "protection" on macs used for development (according to the linked comments, boot in "recovery mode", run csrutil disable).
Regards, /Niels
On Wed, Apr 1, 2020 at 2:06 AM Niels Möller nisse@lysator.liu.se wrote:
Jeffrey Walton noloader@gmail.com writes:
Tested mostly OK on my mac-mini:
Thanks for testing.
dyld: Library not loaded: /Users/jwalton/tmp/nettle/lib/libnettle.7.dylib
Is this the expected location after install, from
-install_name ${libdir}/$(LIBNETTLE_SONAME)
on the command linking libnettle.dylib?
I think that is a red herring that will take you down a rabbit hole. On OS X I build with -Wl,-rpath,@loader_path/../lib. Eventually, when the library is installed, it will be a good path.
But I don't think it is the problem here. The problem here seems to be DYLD_LIBRARY_PATH is empty, so the loader is falling back to the rpath.
Then maybe using DYLD_FALLBACK_LIBRARY_PATH could work a bit better, if the runtime linker only looks for libnettle.7.dylib in the given install location, and not in system directories. Will still not be correct if you install into a location where you have an older version but with the same soname, but at least will be correct in some more cases?
Referenced from: /Users/jwalton/Build-Scripts/nettle-master/testsuite/../tools/sexp-conv Reason: image not found cmp: EOF on test1.out FAIL: sexp-conv FAIL: pkcs1-conv FAIL: nettle-pbkdf2
The three failing tests are /bin/sh scripts running the binaries in tools/. I guess those still have DYLD_LIBRARY_PATH dropped from the environment, can you confirm?
To me, "system integrity protection", dropping DYLD_LIBRARY_PATH, seems a bit pointless in a setting where we're running code of our choice anyway.
Do you see any clean workaround? One could maybe delegate it further, similar to how $EMULATOR is handled.
Well, you patched run-tests, but you did not patch the other scripts. Maybe patch the other scripts?
I patch the other scripts and don't have a problem. I think the other scripts include testsuite/nettle-pbkdf2-test, testsuite/sexp-conv-test, testsuite/pkcs1-conv-test, examples/rsa-encrypt-test, examples/rsa-verify-test and examples/rsa-sign-test.
I believe some of the other scripts need patching because a call chain looks sometimes like the following.
run-tests => testsuite/sexp-conv-test => sexp-conv run-tests => testsuite/pkcs1-conv-test => pkcs1-conv run-tests => testsuite/nettle-pbkdf2-test => nettle-pbkdf2
(I did not study it in great detail, so I may be wrong about it. But some of the tests seemed to go outside of run-tests. The place to patch seems to be the last script before [compiled] test program is called).
Another workaround may be, provide a run-tests.in, testsuite/sexp-conv-test.in and friends. And then let Autotools patch the path into the scripts with a variable like @nettle_testlibdir@.
Jeff
Hello Niels,
On Tue, Mar 31, 2020 at 08:08:35PM +0200, Niels Möller wrote:
I think a reasonable way is to add
abs_top_builddir = @abs_top_builddir@
TEST_SHLIB_DIR = "${abs_top_builddir}/.lib"
to config.make.in, and use that to set LD_LIBRARY_PATH. And possibly only pass TEST_SHLIB_DIR to the run-tests script, and move the logic to setup the environment.
I've pushed a change like that to the branch test-shlib-dir. Please try it out.
The change also makes the testsuite work with uClibc in default configuration where relative paths are not allowed in LD_LIBRARY_PATH.
I have reverted the uclibc armeb CI image to the default configuration of not allowing relative paths in LD_LIBRARY_PATH.
I can confirm that the testsuite now fails for branch master-updates (https://gitlab.com/michaelweiser/nettle/-/jobs/493643301) and works for branch test-shlib-dir (https://gitlab.com/michaelweiser/nettle/-/jobs/493645063).
BTW: Should we have a note in the code or commit message as to *why* we're changing it? Nobody will remember in a few months time. ;)
nettle-bugs@lists.lysator.liu.se
-
Jeffrey Walton -
Michael Weiser -
nisse＠lysator.liu.se