Bug #315
closedlibgwenhyfar 5.12 fails to configure with libgcrypt >= 1.11 (linux)
Description
Hi,
I tried to build the newest aqbanking (6.6.0) + libgwenhyfar for my Arch-System.
Configure for libgwenhyfar 5.12.0 failed to configure with an error "libgcrypt not found".
I examined the situation and found that libgcrypt + headers IS present on my system in version 1.11 - but configure did not find it because it relies on "libgcrypt-config" to find the correct version + path.
In libgcrypt 1.11 (at least on linux), libgcrypt-config was removed, instead they provide a pkg-config now.
So, the configure-script/macros need to be adapted from libgcrypt-config to pkgconfig.
Other projects with similar problems can be found by an internet search for "libgcrypt 1.11 migrate from libgcrypt-config to pkg-config", also e.g.: https://dev.gnupg.org/T7114
Sorry - I'm not firm enough in either pkgconfig nor in autoconf to provide a patch, even if several maintainers of other projects tell in the respective bugs "it's an easy fix" (not for me ;) ).
I was able to workaround by temporarily downgrading to libgcrypt 1.10 , but in the long term, the configure script should be adapted.
Ich kann auch gerne Feedback/Beschreibung auf Deutsch liefern ;)
Updated by merlinwv about 1 year ago
- Subject changed from libgwenhyfar 5.12 falis to configure with libgcrypt >= 1.11 (linux) to libgwenhyfar 5.12 fails to configure with libgcrypt >= 1.11 (linux)
Updated by mlenk about 1 year ago
Debian builds don't fail, despite they build with libgcrypt 1.11 too.
Example build log: https://buildd.debian.org/status/fetch.php?pkg=libgwenhywfar&arch=amd64&ver=5.12.0-1&stamp=1734594288&raw=0
Apparently this is actually a matter of the aclocal.m4 file shipped with Gwenhywfar being out of date. It includes a copy of some (unclear origin) libgcrypt.m4, which seems to be updated last in 2018 (at least the aclocal.m4 file committed in Git says).
Debian builds don't fail because the automake/autoconf things are rebuilt from source on every build.
Another way to work around it is to update the aclocal.m4 (and other files) by calling
make -f Makefile.cvs
before build.
Suggestion for fixing it in the Gwenhywfar project:
Either update the compiled things regularly, or don't commit/ship them at all.
I have no strong opinion on this.
Updated by martin 4 months ago
- Status changed from New to Feedback
Also die Datei aclocal.m4 muss schon mitgeliefert werden, weil sonst beim Benutzer des tarballs auch die ganze autoconf-Flotte vorhanden sein muss, und das kann wieder seine eigenen Probleme machen, wenn da die Versionen nicht stimmen etc.
Also sollte am besten die aclocal beim Bauen des tarballs neu erzeugt werden... Ich haette angenommen, dass das auch so passiert, aber scheinbar nicht.