On 12.07.2019 21:21, Konstantin Ryabitsev wrote:
> Hi, all:
>
> I provide an RPM package called gnupg22-static for those who need to run
> newer versions of GnuPG on CentOS-7 environments (it's stuck on
> gnupg-2.0 there). For compilation, I use the convenient STATIC=1
> mechanism, but there's still the problem that all paths end up being
> hardcoded to the RPM buildroot environment.
>
> The full build command is:
> make -f build-aux/speedo.mk STATIC=1 CUSTOM_SWDB=1 INSTALL_PREFIX=.
> this-native
> In the RPM context, the INSTALL_PREFIX ends up being inside a buildroot
> location, like so:
>
> /builddir/build/BUILD/gnupg-2.2.17/
>
> However, the final installation of this will be in /opt/gnupg22, which
> means that if a binary needs to call another binary, it will try to
> execute /builddir/build/BUILD/gnupg-2.2.17/bin/foo (and fail).
>
> I can't set INSTALL_PREFIX=/opt/gnupg22, because that will make the RPM
> build fail (it cannot write outside of /builddir), so I need a way to
> tell the binaries during build time that their final install path will
> be different than the path used during build.
> I am able to use gpg and gpgv this way by setting agent-program and
> dirmngr-program config values, but trying to make this work with
> gpg-wks-server fails.
>
> Any pointers on how I can make this work without hardcoding bogus
> build-time paths?
I have the same situation for building gpgOSX. The solution is this:
./configure \
--with-pinentry-pgm=${TARGET_DIR}/bin/pinentry \
--with-agent-pgm=${TARGET_DIR}/bin/gpg-agent \
--with-scdaemon-pgm=${TARGET_DIR}/libexec/scdaemon \
--with-dirmngr-pgm=${TARGET_DIR}/bin/dirmngr \
--with-dirmngr-ldap-pgm=${TARGET_DIR}/libexec/dirmngr_ldap \
--with-protect-tool-pgm=${TARGET_DIR}/libexec/gpg-protect-tool \
etc.
-Patrick
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
