User Details
- User Since
- Aug 1 2019, 10:54 AM (280 w, 2 d)
- Availability
- Available
May 14 2024
Thanks, I confirm that this new commit is fixing the issue.
May 12 2024
Build is still failing even with this commit, here is an extract of npth log:
May 5 2024
Aug 31 2022
GnuPG requires threads but not gpgme.
We already had the same discussion about threads and libgpg-error more than one year ago: https://dev.gnupg.org/T5296
Aug 27 2022
Sep 5 2021
Nevermind, I found the appropriate link above, thanks again.
Thanks for noticing me but I can't access your git repository at https://dev.gnupg.org/source/gnupg.git and the github mirror at https://github.com/gpg/gpgme is not up to date. Do you have an other mirror?
Jun 19 2021
Feb 15 2021
I was not the author of the host "hacking" which has been committed to buildroot in 2016 by https://git.buildroot.net/buildroot/commit/package/?id=2f89476ad98b82ea9f914337b0050c4808082c82 so I can't really comment on it.
You can find more information here: https://patchwork.ozlabs.org/project/buildroot/patch/1451762923-15985-1-git-send-email-joerg.krause@embedded.rocks/
Especially, it seems that Jörg Krause started a discussion about this issue and proposed a patch to fix the architecture depends but it was never applied. Unfortunately, I wasn't able to find more information as it seems that links on comments.gmane.org are broken ...
This won't work in the context of buildroot as we're passing --host="arm-unknown-linux-gnueabi" to avoid the following build failure:
Feb 12 2021
Because, threads are optional on uclibc as threads are not supported by all embedded targets.
libgpg-error was building perfectly fine without threads until version 1.40 as all pthread calls were protected by USE_POSIX_THREADS.
Should I understand from your answer that threads are now mandatory?
Jan 22 2021
It seems that this issue has already been reported with a better fix: https://lists.gnupg.org/pipermail/gcrypt-devel/2021-January/005060.html
Feel free to close this issue.
Aug 13 2019
Fixing t-lock is indeed a better solution however having an option to disable tests could be used in another context than fixing this issue.
For example, in the context of buildroot (which goal is to build a custom embedded linux system), this option could be used to save time during compilation as well as to save space on the embedded system.