On Apr 22, 2021, at 00:09, Marcus Calhoun-Lopez wrote:
> I must admit that whan issues like code signing come up, I tend to
> tune out, so please forgive me if this is well trodden territory.
>
> While working on the netgen, I added the following code to get the
> destroot phase working (where ${pdv} is 3.8, 3.9, etc.):
> destroot.env-append
> PYTHONPATH=${destroot}${prefix}/lib/python${pdv}/site-packages/ \
>
> DYLD_LIBRARY_PATH=${destroot}${prefix}/lib
>
> In the CMake file, PYTHONPATH is respected by execute_process [1], but
> DYLD_LIBRARY_PATH is not.
> From what I can tell, this is an OS issue and not a cmake problem [2].
> Apparently, the solution is to run codesign on cmake.
> Is this at all feasible?
> Is there another possible workaround anyone can think of?
> I am afraid I know little to nothing about how codesign [3] works.
>
> Thank you,
> Marcus
>
> [1] https://cmake.org/cmake/help/latest/command/execute_process.html
> [2] https://gitlab.kitware.com/cmake/cmake/-/issues/20678
> [3]
> https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html
https://gitlab.kitware.com/cmake/cmake/-/issues/20678 seems to be about
restrictions encountered when using a binary distributed by cmake.org. The
reporter said he did not experience those restrictions when building cmake
himself or when using cmake from Homebrew, so I would not expect you to
experience those restrictions with cmake from MacPorts either. Presumably the
binary from cmake.org is built with settings (hardened runtime?) that cause
this to occur, settings that we are presumably not using.
DYLD_LIBRARY_PATH needs to be set when invoking the binary that needs it. Ever
since OS X 10.11, DYLD environment variables are not inherited by subprocesses,
so you can't just set it at the top level and expect it to be there in whatever
subprocess or subsubprocess needs it. (Other environment variables are still
inherited.) So you might need to follow the execution path a little and figure
out where the executable that needs DYLD_LIBRARY_PATH is being run and set
DYLD_LIBRARY_PATH when running it.
