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