Bug #315
offenlibgwenhyfar 5.12 fails to configure with libgcrypt >= 1.11 (linux)
Beschreibung
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 ;)
Von merlinwv vor 10 Monaten aktualisiert
- Thema wurde von libgwenhyfar 5.12 falis to configure with libgcrypt >= 1.11 (linux) zu libgwenhyfar 5.12 fails to configure with libgcrypt >= 1.11 (linux) geändert
Von mlenk vor 10 Monaten aktualisiert
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.
Von martin vor 24 Tagen aktualisiert
- Status wurde von New zu Feedback geändert
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.