Bug 194176 - security/cyrus-sasl2-gssapi libraries do not include RPATH
Summary: security/cyrus-sasl2-gssapi libraries do not include RPATH
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Hajimu UMEMOTO
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-06 01:10 UTC by Erick Turnquist
Modified: 2014-10-09 13:23 UTC (History)
0 users

See Also:
jhujhiti: maintainer-feedback? (ume)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erick Turnquist 2014-10-06 01:10:01 UTC
I can't figure this one out. At some point between r337435 and now, the resultant libgssapiv2.so from this port stopped including RPATH. My LOCALBASE and PREFIX are set to /usr/pkg.

An old installation:
% readelf -d /usr/pkg/lib/sasl2/libgssapiv2.so | grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [/usr/pkg/lib:/usr/lib:/usr/pkg/lib]
%

A new installation, built with the latest port:
% readelf -d /usr/pkg/lib/sasl2/libgssapiv2.so | grep RPATH
%

This has the effect of causing the linker to find libraries in /usr/lib instead of /usr/pkg/lib. Since I am building against MIT krb5 instead of Heimdal, this breaks the port.

Old installation:
% ldd /usr/pkg/lib/sasl2/libgssapiv2.so | grep libgssapi_krb5
        libgssapi_krb5.so => /usr/pkg/lib/libgssapi_krb5.so (0x801607000)

New installation:
% ldd /usr/pkg/lib/sasl2/libgssapiv2.so | grep libgssapi_krb5
        libgssapi_krb5.so => /usr/lib/libgssapi_krb5.so (0x801607000)

The port's Makefile does specify the RPATH in MIT_LDFLAGS, but libtool isn't respecting it. While building:

/bin/sh ../libtool   --mode=link  cc  -Wall -W -O2 -pipe -fno-strict-aliasing -module -export-dynamic -rpath /usr/pkg/lib/sasl2 -version-info 3:0:0 -Wl,-rpath,/usr/pkg/lib -Wl,-rpath,/usr/lib:/usr/pkg/lib -L/usr/pkg/lib -o libgssapiv2.la  gssapi.lo gssapiv2_init.lo  plugin_common.lo -L/usr/pkg/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support

This is the correct RPATH in -Wl. However, the output from this libtool invocation does not include the -rpath:

rm -fr .libs/libgssapiv2.la .libs/libgssapiv2.* .libs/libgssapiv2.*
cc -shared  gssapi.lo gssapiv2_init.lo plugin_common.lo  -L/usr/pkg/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lc  -Wl,-soname -Wl,libgssapiv2.so.3 -o .libs/libgssapiv2.so.
3.0.0
(cd .libs && rm -f libgssapiv2.so.3 && ln -s libgssapiv2.so.3.0.0 libgssapiv2.so.3)
(cd .libs && rm -f libgssapiv2.so && ln -s libgssapiv2.so.3.0.0 libgssapiv2.so)
ar cru .libs/libgssapiv2.a  gssapi.o gssapiv2_init.o plugin_common.o 
ranlib .libs/libgssapiv2.a
Comment 1 Bugzilla Automation freebsd_committer 2014-10-06 01:10:01 UTC
Auto-assigned to maintainer ume@FreeBSD.org
Comment 2 Erick Turnquist 2014-10-07 00:42:59 UTC
I've found an old poudriere log and realized that, whereas libtool is currently being called as "/bin/sh ../libtool", previous successful builds had been calling just "libtool" (that is, using the system libtool). I was unable to get the current environment to call system libtool, except by manually editing the Makefile. After the edit, libtool correctly generates the libraries with RPATH set.

Since this is the same upstream version, something must have changed in the port environment.
Comment 3 commit-hook freebsd_committer 2014-10-09 13:19:15 UTC
A commit references this bug:

Author: ume
Date: Thu Oct  9 13:18:29 UTC 2014
New revision: 370526
URL: https://svnweb.freebsd.org/changeset/ports/370526

Log:
  Include RPATH in the libs, again.
  It seems that USES=libtool doesn't rewrite ${LIBTOOL} in
  a configure script to use ${LOCALBASE}/bin/libtool like
  bsd.autotools.mk did.
  So, rewrite it explicitly for workaround.

  PR:		194176
  Submitted by:	jhujhiti__at__adjectivism.org

Changes:
  head/security/cyrus-sasl2-gssapi/Makefile
Comment 4 Hajimu UMEMOTO freebsd_committer 2014-10-09 13:23:02 UTC
It should be fixed by r370526.
It seems that USES=libtool doesn't rewrite ${LIBTOOL} in a configure script to use ${LOCALBASE}/bin/libtool like bsd.autotools.mk did.
So, rewrite it explicitly for workaround.