dylibbundler doesn't rewrite paths correctly when using alternative library search path

[Kreeblah]

I'm figuring out what my options are for cross compiling the dxx-rebirth project are using osxcross on a Linux host, and I'm finding that dylibbundler is behaving differently than I'd expect when I try to use it to bundle libraries in.

Because dylibbundler relies on Mac-native tools (some of which don't have Linux equivalents), I copied my resulting app bundle to my Mac along with the libraries the build process used. I use Homebrew on my Mac, but osxcross gets libraries from MacPorts, hence copying the libraries over.

What I'm seeing is that when dylibbundler calls install_name_tool, it passes the location it actually found the library in as the value of the -change parameter, which doesn't end up doing anything, since the value there has to match what the binary already has as a library location.

For example, running the following:

dylibbundler -od -b -x build/D1X-Rebirth.app/Contents/MacOS/d1x-rebirth -d build/D1X-Rebirth.app/Contents/libs -s /Users/kreeblah/macports_libs/

Part of the output there is:

    install_name_tool -change "/Users/kreeblah/macports_libs/libpng16.16.dylib" "@executable_path/../libs/libpng16.16.dylib" "build/D1X-Rebirth.app/Contents/MacOS/d1x-rebirth"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: build/D1X-Rebirth.app/Contents/MacOS/d1x-rebirth

Note the -change "/Users/kreeblah/macports_libs/libpng16.16.dylib" part. However, if I run otool -l build/D1X-Rebirth.app/Contents/MacOS/d1x-rebirth, this is part of the output:

Load command 13
          cmd LC_LOAD_DYLIB
      cmdsize 64
         name /opt/local/lib/libpng16.16.dylib (offset 24)
   time stamp 2 Wed Dec 31 16:00:02 1969
      current version 56.0.0
compatibility version 56.0.0

From the man page for install_name_tool:

       -change old new
              Changes the dependent shared library install name old to new in
              the specified Mach-O binary.  More than one of these options can
              be specified.  If the Mach-O binary does not contain the old
              install name in a specified -change option the option is
              ignored.

So, it seems that by using the -s option to look for libraries in an alternative path, those libraries do get copied into the bundle, but nothing gets its paths updated (this impacts libraries that have dependencies as well).