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. -- Best wishes, Michael _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
