On Tue, Mar 31, 2020 at 6:30 AM Michael Weiser <[email protected]> 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-breaks-dyld-library-path-for-python-scripts 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): > > 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. (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 _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
