Help Understanding Code Signing

Ryan Schmidt ryandesign at
Thu Apr 22 06:57:49 UTC 2021

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
> 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]
> [2]
> [3] seems to be about restrictions encountered when using a binary distributed by 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 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.

More information about the macports-dev mailing list