Mailing List Archive

[PATCH] Add rpath so the Qt libs are found at runtime
From 24261594a341d15baca0a19b415be1dab5370f70 Mon Sep 17 00:00:00 2001
From: David Faure <faure@kde.org>
Date: Sat, 21 Dec 2019 21:04:35 +0100
Subject: [PATCH] Add rpath so the Qt libs are found at runtime

This is necessary when Qt is installed into a custom prefix.
---
configure.ac | 1 +
m4/qt.m4 | 5 +++++
qt/Makefile.am | 1 +
3 files changed, 7 insertions(+)

diff --git a/configure.ac b/configure.ac
index 0392203..9daa65d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -556,6 +556,7 @@ fi

AC_SUBST(PINENTRY_QT_CFLAGS)
AC_SUBST(PINENTRY_QT_LIBS)
+AC_SUBST(PINENTRY_QT_LDFLAGS)
AC_SUBST(MOC)

dnl If we have come so far, qt pinentry can be build.
diff --git a/m4/qt.m4 b/m4/qt.m4
index 35d9ae2..f8ef3f6 100644
--- a/m4/qt.m4
+++ b/m4/qt.m4
@@ -57,6 +57,11 @@ AC_DEFUN([FIND_QT],
PINENTRY_QT_CFLAGS="$PINENTRY_QT_CFLAGS -std=c++11"
fi

+ qtlibdir=`"$PKG_CONFIG" --variable libdir Qt5Core`
+ if test -n "$qtlibdir"; then
+ PINENTRY_QT_LDFLAGS="$PINENTRY_QT_LDFLAGS -Wl,-rpath \"$qtlibdir\""
+ fi
+
AC_CHECK_TOOL(MOC, moc)
AC_MSG_CHECKING([moc version])
mocversion=`$MOC -v 2>&1`
diff --git a/qt/Makefile.am b/qt/Makefile.am
index 840d0c0..14d9a0f 100644
--- a/qt/Makefile.am
+++ b/qt/Makefile.am
@@ -41,6 +41,7 @@ AM_CXXFLAGS = $(PINENTRY_QT_CFLAGS)
pinentry_qt_LDADD = \
../pinentry/libpinentry.a $(top_builddir)/secmem/libsecmem.a \
$(COMMON_LIBS) $(PINENTRY_QT_LIBS) $(libcurses) $(LIBCAP)
+pinentry_qt_LDFLAGS = $(PINENTRY_QT_LDFLAGS)

BUILT_SOURCES = \
pinentryconfirm.moc pinentrydialog.moc pinlineedit.moc

--
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH] Add rpath so the Qt libs are found at runtime [ In reply to ]
Hi David,

Thanks for the Patch. I've pushed it.

Best Regards,
Andre

--
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board@gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799
Re: [PATCH] Add rpath so the Qt libs are found at runtime [ In reply to ]
On Sun 2019-12-22 10:11:56 +0100, David Faure wrote:
> Subject: [PATCH] Add rpath so the Qt libs are found at runtime
>
> This is necessary when Qt is installed into a custom prefix.
[…]
> --- a/m4/qt.m4
> +++ b/m4/qt.m4
> @@ -57,6 +57,11 @@ AC_DEFUN([FIND_QT],
> PINENTRY_QT_CFLAGS="$PINENTRY_QT_CFLAGS -std=c++11"
> fi
>
> + qtlibdir=`"$PKG_CONFIG" --variable libdir Qt5Core`
> + if test -n "$qtlibdir"; then
> + PINENTRY_QT_LDFLAGS="$PINENTRY_QT_LDFLAGS -Wl,-rpath \"$qtlibdir\""
> + fi
> +

hm, this *isn't* actually necessary on some platforms (debian, at least)
where "pkg-config --variable libdir Qt5Core" is non-empty.

0 dkg@alice:~$ pkg-config --variable libdir Qt5Core
/usr/lib/x86_64-linux-gnu
0 dkg@alice:~$

(pinentry-qt does work fine on debian, without this patch)

Furthermore, RPATH is discouraged on debian, and has been for ages.
Details here:

https://wiki.debian.org/RpathIssue

I'd rather not have to revert this patch in debian; is there some better
test that can be used? or can we add a flag to configure that will
avoid setting rpath?

--dkg
Re: [PATCH] Add rpath so the Qt libs are found at runtime [ In reply to ]
On Thu 2020-03-26 22:36:28 +0100, David Faure wrote:
> - provide a way to turn it all off

this sounds a lot simpler than trying to guess whether a given library
path is expected to be a system path. I'd even argue for default-off
(not default-on), but i could live with either.

I'd really rather avoid having to patch the pinentry sources to avoid
this though.

> Unfortunately my autoconf abilities are too limited for me to provide this....

Perhaps wrapping the line in configure.ac with an "--with-qt-rpath" flag
or something? I would also happily yield to someone with better
autoconf skills than myself here.

> I could provide a cmake port though ;-)

no comment ;)

--dkg