Any experts on using path in app bundles willing to help me?
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? _,,,^..^,,,_ best, Eliot
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
On Fri, 19 Apr 2019 at 01: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
Interesting reading. thx for the links. cheers -ben
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/... <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos64x64/...> 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 <mailto: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://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e41...> https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath <https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath>
_,,,^..^,,,_ best, Eliot
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
On 19 Apr 2019, at 20:38, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Esteban,
On Fri, Apr 19, 2019 at 12:51 AM Esteban Lorenzano <estebanlm@gmail.com <mailto: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/... <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.
Yes, this is an inherited situation and I ignore the rationale behind it. I agree this way of distributing is not appropriate but I just didnât have the time to fix it (because after all, it is working so I always have something more urgent to do). Esteban
Esteban
On 18 Apr 2019, at 19:35, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
On Thu, Apr 18, 2019 at 10:08 AM Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote: Hi All,
I have a plugin dependent on several support libraries that ma y 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://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e41...> https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath <https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath>
_,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
participants (3)
-
Ben Coman -
Eliot Miranda -
Esteban Lorenzano