Avoiding hardcoded paths when static-compiling

[Patrick Brunschwig]

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