gdal: restore patch-build_with_install_name_dir.diff

The patch was removed in cf569f1e94, but it’s still necessary. While
the patch has been accepted upstream, it wasn’t backported to gdal-3.13,
so it is not possible to remove the patch until a future update to
gdal-3.14.

gis/gdal/Portfile

@@ -10,7 +10,7 @@ name                gdal
 # keep version in sync with py-gdal; rev-bump dependents after an
 # install_name-changing update (typically when a or b changes in version a.b.c).
 version             3.13.1
-revision            0
+revision            1
 
 checksums           rmd160  a21330e04ab00d8dc89f8d1f3d5c9858cb948db0 \
                     sha256  7398fb132753140740fac4f099f0dbe49d1ad074c4162290c308e067c46b7f92 \
@@ -86,7 +86,8 @@ depends_lib-append \
                     port:zlib \
                     port:zstd
 
-patchfiles-append   patch-gtiffdataset.diff
+patchfiles-append   patch-build_with_install_name_dir.diff \
+                    patch-gtiffdataset.diff
 
 # By default, disable all drivers
 configure.args-append                                        \

gis/gdal/files/patch-build_with_install_name_dir.diff

@@ -0,0 +1,53 @@
+https://github.com/OSGeo/gdal/commit/18f84029c14d080343072b01793169ee19102209.patch
+
+From 4fc310dd6d0a95bedda003613cfa63ded090d5fa Mon Sep 17 00:00:00 2001
+From: Mark Mentovai <mark@mentovai.com>
+Date: Tue, 26 May 2026 12:02:07 -0400
+Subject: [PATCH] CMake: set BUILD_WITH_INSTALL_NAME_DIR for macOS
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+CMake can either build shared libraries with a temporary install_name at
+build time, resetting it to the final name at install time
+(BUILD_WITH_INSTALL_NAME_DIR=NO, the default), or it can build them with
+the final name at build time (BUILD_WITH_INSTALL_NAME_DIR=YES).
+
+GDAL plugins link against libgdal as part of the build process, and if
+BUILD_WITH_INSTALL_NAME_DIR=NO, these plugins may be linked using an
+incorrect path to libgdal, taken from libgdal’s install_name. Those
+paths are not rewritten at install time, which can make it difficult to
+properly use GDAL plugins built in this way. For example, with GDAL
+built with a CMAKE_INSTALL_NAME_DIR set (as a downstream build may do),
+and PDF built as a plugin, `gdal info` on a PDF may fail with an error
+such as:
+
+```
+ERROR 1: dlopen(…/lib/gdalplugins/gdal_PDF.dylib, 0x0001): Library not loaded: @rpath/libgdal.39.dylib
+  Referenced from: <…> …/lib/gdalplugins/gdal_PDF.dylib
+  Reason: no LC_RPATH's found
+```
+
+Setting BUILD_WITH_INSTALL_NAME_DIR=YES overcomes this problem. This
+change should be noncontroversial, as the default GDAL build, without a
+CMAKE_INSTALL_NAME_DIR set, will use @rpath as the install_name_dir in
+both the build and installed trees, regardless of the setting of
+BUILD_WITH_INSTALL_NAME_DIR.
+---
+ gdal.cmake | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git gdal.cmake gdal.cmake
+index b629bdb1ab1c..63295bcd78c6 100644
+--- gdal.cmake
++++ gdal.cmake
+@@ -234,7 +234,8 @@ set_target_properties(
+              LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
+              RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
+              CXX_STANDARD 11
+-             CXX_STANDARD_REQUIRED YES)
++             CXX_STANDARD_REQUIRED YES
++             BUILD_WITH_INSTALL_NAME_DIR YES)
+ set_property(TARGET ${GDAL_LIB_TARGET_NAME} PROPERTY PLUGIN_OUTPUT_DIR "${CMAKE_CURRENT_BINARY_DIR}/gdalplugins")
+ file(MAKE_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/gdalplugins")
+