Fail to install git from macports ("can't find file to patch" error)

[Clemens Lang]

Hi,

----- On 20 Feb, 2018, at 15:34, Joshua Kordani jkordani at lsa2.com wrote:

> Not the OP, but regarding DYLD_LIBRARY_PATH, I don't understand how to
> make use of dylib's provided by macports in my own programs without
> setting this flag.  I've read in several places that, esp with macports,
> this should not be necessary, but I don't know what the *right way* is.

macOS is not Linux in this regard. macOS libraries are referenced from
binaries using their absolute path.

At a technical level, when you link a binary with, for example, -lcurl on
the command line, the linker will locate libcurl.dylib in the search paths
you've given on the command line (that should be -L/opt/local/lib for use
with MacPorts). It will then read the library id from the file. For our
example of MacPorts' libcurl, this is:

 $> otool -D /opt/local/lib/libcurl.dylib
 /opt/local/lib/libcurl.4.dylib

This path will then be copied into the linked binary. You can verify this
with the MacPorts curl binary:

 $> otool -L /opt/local/bin/curl | grep libcurl
 /opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)

When you run /opt/local/bin/curl, the loader reads this table and locates
this file using its absolute path. Setting DYLD_LIBRARY_PATH overrides this
and attempts to locate a file with the given basename in the directories
given in DYLD_LIBRARY_PATH, but if the library and the binary have been
built correctly (and not moved) you should never have to set it.

Of course this makes your binaries non-relocatable. If you want to relocate
binaries, you can use relative paths using the special variables @loader_path,
@executable_path and @rpath. See the dylibbundler port, which largely
automates this if you built your binaries with the -headerpad_max_install_names
linker flag (which MacPorts does by default).

-- 
Clemens Lang