Page MenuHome GnuPG
Create Task
Maniphest T5954

Building for windows requires gpgrt (libgpg-error) 1.45, but configure.ac claims 1.27
Closed, WontfixPublic
Actions

Description

In rG70b738f93f1ae6b606af701f6def55a6f0f3d04b and rG6afedbcd47d9a7d433cebf68bccabd47ba776e0f , GnuPG 2.2.35 builds for Windows end up needing gpgrt_fname_to_wchar, which was only introduced in gpgrt (or libgpg-error) 1.45.

However, configure.ac says:

NEED_GPG_ERROR_VERSION=1.27

This has an impact on the debian builds, which create a windows executable for gpgv when building for architecture-independent packages (for use with debian installers that launch from windows).

Not a high priority for me, but i thought you might want to be aware of the inconsistency in the codebase.

Details

Version
2.2.35

Related Objects

Event Timeline

dkg created this task.Apr 28 2022, 4:38 AM
• werner closed this task as Wontfix.Apr 28 2022, 8:45 AM
• werner claimed this task.
• werner added a subscriber: • werner.

Use our build system and things work. In particular you need to use the software versions as listed at versions.gnupg.org and available via the build-auch/getswdb.sh. Even better use the speedo build system for Windows. Everything else is not a supported build configuration.

dkg added a comment.May 2 2022, 6:03 PM

Debian requires all builds to use software that we have local copies of in the archive, which appears to rule out the use of speedo (it fetches source over the internet during build). So i've modified debian packaging to annotate that the Windows builds need a different version of libgpg-error than that defined in configure.ac.

It would be more straightforward for downstream maintainers to deal with this if the internal annotations in the shipped build infrastructure (e.g. the explicit tests in configure.ac) could accurately reflect the upstream expectations. That seems relatively easy to do by adjusting the value of NEED_GPG_ERROR_VERSION based on the target architecture. Maybe you could make that change for users whose constraints prohibit them from running speedo?

Anyway, I've noted here what we've done in debian in the hope of helping other downstream distributors that might run into the same problem.