Blair Sadewitz wrote:
> This latest change--I think--causes the library search paths to be
> checked as absolute pathnames; the actual run paths are not going to
> include ${DESTDIR} if destdir support is being used.
> I am not sure what the proper fix is [yet].  Anyone experience this?

If you refer to the change from r1.9 to r1.10 then I am responsible.

For some time the files in ${PLIST} (=${WRKDIR}/.PLIST) have had relative
path names and r1.9 of check-shlibs used a check with an extended regular
expression like this

 egrep -h '/(bin/|sbin/|libexec/|lib/lib.*\.so|lib/lib.*\.dylib)' 

This expression did not catch those files

  bin/lua
  bin/luac
  lib/liblua.so
  lib/liblua.so.5
  lib/liblua.so.5.0.1

while the new regular expression without the leading slash _does_
extract those libraries from .PLIST.

Now that I think some more about this, I see that there is still a
different problem which we notice only now because of the fix above.
Before that, no binary or library was ever checked since the switch
to relative path names.
You are correct, the files record only library search paths like
  RPATH       /usr/pkg/lib

and thus the check "ldd bin/lua" tells us

  -llua.5 => not found

In order to do the right thing, we might extract the DT_RPATH entries
from ELF files and construct a set of paths to use for LD_LIBRARY_PATH

  $ DESTDIR=/scr/tmp/pkgsrc/lang/lua/work.i386/.destdir
  $ PREFIX=/usr/pkg
  $ cd ${DESTDIR}${PREFIX}
  $ RPATH=$(somehow extract DT_RPATH /usr/pkg/lib and remove leading slash)
  $ LD_LIBRARY_PATH=${RPATH} ldd bin/lua
  /scr/tmp/pkgsrc/lang/lua/work.i386/.destdir/usr/pkg/bin/lua:
        -lm.0 => /usr/lib/libm387.so.0
        -lm.0 => /usr/lib/libm.so.0
        -ledit.2 => /usr/lib/libedit.so.2
        -ltermcap.0 => /usr/lib/libtermcap.so.0
        -llua.5 => usr/pkg/lib/liblua.so.5
        -lc.12 => /usr/lib/libc.so.12

How do we do that in a platform independent way, eg, for platforms not
using ELF or not supporting LD_LIBRARY_PATH?

If i remember correctly, Debian builds (Gentoo as well?) handle such
problems by loading special libraries to fake a kind of chroot(2) call to
${DESTDIR}.

ciao
     Klaus