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.