[MacPorts] #60366: liblas: Duplicate -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib flag and reintroduction of rpath

[MacPorts]

#60366: liblas: Duplicate -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib flag and
reintroduction of rpath
-------------------------+--------------------
  Reporter:  ryandesign  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.6.2
Resolution:              |   Keywords:
      Port:  liblas      |
-------------------------+--------------------

Comment (by mathstuf):

 Adapting the emails I sent:

 >  In [0f281244b3d78d09dd057034a5e386c6f0e353e1/macports-ports] a
 duplicate
 >  `-DCMAKE_INSTALL_NAME_DIR=${prefix}/lib` flag was added to the port.
 This
 >  is pointless since the cmake portgroup already adds this so the
 duplicate
 >  flag should be removed.

 Ah, I didn't see that it was already there. Mainly because the install
 name should be `$prefix/lib` with this patch, not @rpath as you're
 seeing. I'm pretty sure I had absolute paths in my library IDs when I
 tested it locally, but maybe that wasn't true after the rebase.

 The main issue with @rpath is that an `-Wl,-rpath,$dir` needs added to
 all linking executables in order to find any libraries using @rpath.
 CMake doesn't do this today (mainly because it doesn't know which
 linked-to libraries are using @rpath or how deep they expect to be from
 there). For example, Qt frameworks use `@rpath/QtCore.framework/QtCore`,
 so you need to go up 2 directories to get the proper rpath entry for
 that.

 >  Is this reintroduction of rpath ok? I don't know. Vincent deliberately
 >  changed the port so that it did not use rpath in
 >  [3d0aac3095640e42fabc64de06f9e16427d2664f/macports-ports] but the
 commit
 >  message doesn't say why. Vincent, do you remember why? Possibly it was
 >  just the usual reason, which is that we don't usually use rpath, for
 one
 >  thing because rpath is not compatible with Mac OS X 10.4. And doesn't
 it
 >  also require every other program/library that uses the library to
 specify
 >  the rpath?

 Unfortunately, that does not come with an explanation about that
 specific bit. But yes, that is the basic issue with @rpath on macOS.

 >  Because the install name of the libraries has changed, all
 >  programs/libraries that link with this library must be revbumped to use
 >  the new install name.

 Technically, no. The library ID is copied at link time into the
 consuming executable. But I can see the argument for consistency. So the
 old path is still used to look up the current libraries. Ideally, it
 wouldn't be doing @rpath even now, but something is busted, so let's
 look at that.

 The reason this came to my attention is because the manual patching was
 not correct on a machine I was working on (the symlink name was used in
 the ID, not the actual library).

 On Fri, Apr 17, 2020 at 18:14:58 -0400, Ben Boeckel wrote:
 > [ Not sure if replying here is reflected on the tracker. ]

 Well, the list rejected my email. Taking them off of this Cc.

 For the record, here was my first stab at fixing the problem I had seen:

     https://github.com/macports/macports-
 ports/commit/2d27d0de01ed80c9a226c0a79b20114721b1ebca

 Here's the patch (in case GitHub expires that commit):

 {{{
 From 2d27d0de01ed80c9a226c0a79b20114721b1ebca Mon Sep 17 00:00:00 2001
 From: Ben Boeckel <ben.boeckel at kitware.com>
 Date: Mon, 14 Oct 2019 14:51:45 -0400
 Subject: [PATCH] liblas: reference liblas by its actual ID

 References between libraries should be consistent. Without looking at
 the filesystem to see that `liblas.3.dylib` and `liblas.2.4.0.dylib` are
 actually the same file (via symlinks), realizing that these are the same
 library with analysis tools can cause false positives.
 ---
  gis/liblas/Portfile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/gis/liblas/Portfile b/gis/liblas/Portfile
 index 4a595c79808..69a11eb44ca 100644
 --- a/gis/liblas/Portfile
 +++ b/gis/liblas/Portfile
 @@ -51,5 +51,5 @@ depends_lib-append  port:boost \
  post-destroot {
      exec install_name_tool -id ${prefix}/lib/liblas.2.4.0.dylib
 ${destroot}${prefix}/lib/liblas.2.4.0.dylib
      exec install_name_tool -id ${prefix}/lib/liblas_c.2.4.0.dylib
 ${destroot}${prefix}/lib/liblas_c.2.4.0.dylib
 -    exec install_name_tool -change "@rpath/liblas.3.dylib"
 ${prefix}/lib/liblas.3.dylib ${destroot}${prefix}/lib/liblas_c.2.4.0.dylib
 +    exec install_name_tool -change "@rpath/liblas.3.dylib"
 ${prefix}/lib/liblas.2.4.0.dylib
 ${destroot}${prefix}/lib/liblas_c.2.4.0.dylib
  }
 }}}

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