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
<cplusplus-sig-bounces+jandyman.voelkel=gmail....@python.org> on behalf of
stefan <ste...@seefeld.name>
Reply-To: Development of Python/C++ integration <cplusplus-sig@python.org>
Date: Wednesday, May 22, 2019 at 11:07 AM
To: "cplusplus-sig@python.org" <cplusplus-sig@python.org>
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
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig
