On Tue, Mar 31, 2020 at 6:44 AM Jeffrey Walton <[email protected]> wrote: > > 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.
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 _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
