[squeak-dev] [Pharo-dev] Any experts on using path in app bundles willing to help me?

Eliot Miranda eliot.miranda at gmail.com
Fri Apr 19 18:38:22 UTC 2019


Hi Esteban,

On Fri, Apr 19, 2019 at 12:51 AM Esteban Lorenzano <estebanlm at 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 at gmail.com> wrote:
>
>
>
> On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda at 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-e3e41ae86172
> https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath
>
> _,,,^..^,,,_
> best, Eliot
>
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190419/688e1e03/attachment.html>


More information about the Squeak-dev mailing list