Jeffrey Walton <[email protected]> writes:
> Tested mostly OK on my mac-mini:
Thanks for testing.
> dyld: Library not loaded: /Users/jwalton/tmp/nettle/lib/libnettle.7.dylib
Is this the expected location after install, from
-install_name ${libdir}/$(LIBNETTLE_SONAME)
on the command linking libnettle.dylib?
Then maybe using DYLD_FALLBACK_LIBRARY_PATH could work a bit better, if
the runtime linker only looks for libnettle.7.dylib in the given install
location, and not in system directories. Will still not be correct if
you install into a location where you have an older version but with the
same soname, but at least will be correct in some more cases?
> Referenced from:
> /Users/jwalton/Build-Scripts/nettle-master/testsuite/../tools/sexp-conv
> Reason: image not found
> cmp: EOF on test1.out
> FAIL: sexp-conv
> FAIL: pkcs1-conv
> FAIL: nettle-pbkdf2
The three failing tests are /bin/sh scripts running the binaries in
tools/. I guess those still have DYLD_LIBRARY_PATH dropped from the
environment, can you confirm?
To me, "system integrity protection", dropping DYLD_LIBRARY_PATH, seems
a bit pointless in a setting where we're running code of our choice
anyway.
Do you see any clean workaround? One could maybe delegate it further,
similar to how $EMULATOR is handled.
Otherwise, we may just have to recommend disabling this "protection" on
macs used for development (according to the linked comments, boot in
"recovery mode", run csrutil disable).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
