Hi Esteban, On Fri, Apr 19, 2019 at 12:51 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
yep. The Pharo distribution uses install_name_tool to deal with it, if you want an example already in osvm code:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos64x64/...
It's perhaps a case of "if it ain't broke, don't fixit", but I wonder if it would be better for Pharo to use Frameworks to hold dlls and Resources to hold plugin dlls/bindles. Contents/MacOS/Plugins is, I *think*, unique to Pharo.
Esteban
On 18 Apr 2019, at 19:35, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
I have a plugin dependent on several support libraries that may be shared with other plugins. So I want the support libraries in a common place (TheVm.app/Contents/Frameworks) while the plugins themselves are bundles in TheVM.app/Contents/Resources. In allowing one to install plugin support libraries in TheVM.app/Contents/Frameworks I have to use the linker's -rpath feature to specify where dlopen may find the search libraries. The question i don't see an answer to in Apple's documentation is whether one uses -rpath when linking the plugin, or when linking the VM into which the plugin will be loaded, or both. Anybody ever done this and know definitively what to do?
Never mind. I think I've found what I need:
https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e41... https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath
_,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot