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/third-party/Makefile.libgit2

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:

_,,,^..^,,,_
best,��Eliot




--
_,,,^..^,,,_
best,��Eliot