[MacPorts] #56526: geoexpress-sdk installs dylibs with relative install_name (was: Problem with broken port - GDAL)

[MacPorts]

#56526: geoexpress-sdk installs dylibs with relative install_name
-----------------------------------+----------------------
  Reporter:  news24lor             |      Owner:  Veence
      Type:  defect                |     Status:  assigned
  Priority:  Normal                |  Milestone:
 Component:  ports                 |    Version:  2.4.4
Resolution:                        |   Keywords:
      Port:  geoexpress-sdk, gdal  |
-----------------------------------+----------------------
Changes (by ryandesign):

 * cc: ryandesign (added)
 * port:  gdal => geoexpress-sdk, gdal


Comment:

 There might not be an /opt/local/lib/libltidsdk.9.dylib. It looks like
 /opt/local/share/Geo_DSDK/Raster_DSDK/lib/libltidsdk.9.dylib should be
 provided by the geoexpress-sdk port. You seem to already know that the
 geoexpress-sdk port installs libltidsdk.9.dylib (and all of its other
 libraries, from what I can tell) with a broken (i.e. relative instead of
 absolute) `install_name`, since in the gdal port's +mrsid variant you go
 to the trouble to use `install_name_tool` to fix all references to it in
 gdal—all references except those in `gnmanalyse` and `gnmmanage`.

 Instead of making gdal fix these references, you should correct them at
 the source: in the geoexpress-sdk port. That way, anything that builds
 against the libraries in that port will work correctly without needing to
 be fixed up with `install_name_tool`. It looks like you are already using
 `install_name_tool` in geoexpress-sdk to fix the references to the
 libraries. Now you just need to additionally use `install_name_tool` to
 fix up each library's own id. I did something similar in the `build` phase
 of my oracle-instantclient port if you need an example.

-- 
Ticket URL: <https://trac.macports.org/ticket/56526#comment:7>
MacPorts <https://www.macports.org/>
Ports system for macOS