[OpenSmalltalk/opensmalltalk-vm] 839a5c: MacOS:

 
  Branch: refs/heads/Cog
  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
  Commit: 839a5cab095a76160d4b66c2fcd6e13d898ea0c9
      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/839a5cab095a76160d4b66c2fcd6e13d898ea0c9
  Author: Eliot Miranda <[hidden email]>
  Date:   2020-07-06 (Mon, 06 Jul 2020)

  Changed paths:
    M build.macos32x86/common/Makefile.app
    M build.macos32x86/common/Makefile.flags
    M build.macos32x86/common/Makefile.lib.extra
    M build.macos64x64/common/Makefile.app
    M build.macos64x64/common/Makefile.flags
    M build.macos64x64/common/Makefile.lib.extra
    M platforms/iOS/vm/OSX/sqMacUnixExternalPrims.m

  Log Message:
  -----------
  MacOS:

Revise the install_name_tool machinations in the light of experience with the
Terf plugins and examination of e.g. Xcode,app.  When including dylibs from
elsewhere in Contents/Frameworks they should have an id of @rpath/foo.M.dylib
and access any dylibs they load from Contents/Frameworks should also be named
@rpath/bar.N.dylib, etc.  Likewise the executable should include an rpath
for Contents/Resources (we'd like it to be Contents/PlugIns but this seems to
break something), and Contents/Frameworks.  It turns out that Xcode.app uses
both @executable_path/../Frameworks & @executable_path/../PlugIns.  We're close
but not quite there yet.

Add similar debug printing to tryLoadingLinked as is in tryLoadingInternals.