That is helpful. It might indeed be an issue with System Integrity Protection, now that I do the right google search.
But that leads to the second question. It is possible to indicate within hello_ext.so where to look for the dylib. Then in theory this wouldn’t a problem, because I wouldn’t need to set DYLD_LIBRARY_PATH. Is this insertion of the path of libboost_python37.dylib into hello_ext.so something I can do with bjam, or am I going to have to figure out how to use a separate build system? * Andy From: Cplusplus-sig <[email protected]> on behalf of stefan <[email protected]> Reply-To: Development of Python/C++ integration <[email protected]> Date: Wednesday, May 22, 2019 at 11:07 AM To: "[email protected]" <[email protected]> Subject: Re: [C++-sig] Getting simple boost.python extension to work outside the test scripts - HELP! On 2019-05-22 1:55 p.m., Andrew Voelkel wrote: What magic is the boost environment performing to make this work? What can I do to make my python extensions look for libboost_python37.dylib in the location where it lives? Boost.Build does inject a variety of paths into the system-specific path variable (I believe on MacOS that would be DYLD_LIBRARY_PATH) such that test executables can locate any shared libs they require. But I also remember having seen cases where some OSX releases specifically would prevent that mechanism from working due to some security concerns. I'm not a Mac user, so all of this is second-hand information. Best, [Stefan] -- ...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig
