Bug 194176
| Summary: | security/cyrus-sasl2-gssapi libraries do not include RPATH | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Erick Turnquist <jhujhiti> |
| Component: | Individual Port(s) | Assignee: | Hajimu UMEMOTO <ume> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | Flags: | jhujhiti:
maintainer-feedback?
(ume) |
| Priority: | --- | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
Auto-assigned to maintainer ume@FreeBSD.org 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. 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 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.
|
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