PS I forgot to say why movement to cmake will be the best way.
Feb 7 2020
Jan 2 2020
I totally disagree.
Please read libgpg-error's README. For each architecture we need to have a dedicated config file - this has nothing to do with autotools. Big and little endian variants are obviously different architectures. Here is an excerpt from the README
Jan 1 2020
Hello @wener, I want to say that libgpg-error is the only one (!) application that fails to cross compile using valid toolchains: "armeb-unknown-linux-gnueabi" and "aarch64_be-unknown-linux-gnu". It compiles and runs perfectly using "arm-unknown-linux-gnueabi" and "aarch64-unknown-linux-gnu", but fails with big endian. I see project are actually using "hton/ntoh" so we shouldn't see this error. What this problem is about?
Dec 6 2019
Apr 23 2019
For reference our downstream tracker of this is https://bugs.gentoo.org/683254 including patches
Mar 28 2019
Good that it works again for you.
This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...
May 15 2018
Jul 13 2017
I am closing this, because this particular change was rejected. Eventually libtool might get updated on its own merits, so no need to track this here.
Jul 11 2017
Fixed in 6053cb4f. The third patch was obsolete due to use of FIND_QT macro.
Jun 19 2017
Mar 30 2017
Feb 3 2017
I can still see that qt is using the simplified pkg macros, while the
configure.ac is using proprietary method.
We are still missing PKG_PROG_PKG_CONFIG macro in configure.ac to make pkg
macros happy, this can remove all AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
executions, see pinentry-0.9.5-build.patch, as you have PKG_CONFIG set.
The other changes to use PKG_CHECK_MODULES are optional but is there any reason
why not to use this macro instead of executing the pkg-config manually? This
macro has the advantage of allowing override via environment, and append proper
If you like I can rebase this old patch set.
links removed as I got "Edit Error: not allowed (too many links).
Someone please check whether this is still the case and come up with a fix?
Jan 17 2017
No reply to my question, thus it seems not to be important. Closing.
Note that replying to this will re-open the bug.
Dec 21 2016
Nov 18 2016
Yes, I have seen that URL but what I like to get an answer to my question here
or on gnupg-devel. I do not want to follow a possible long thread of some Linux
Nov 14 2016
There was a long drawn out discussion as to the validity of "-hardfloat" in the
triplet name. You can peruse at https://bugs.gentoo.org/show_bug.cgi?id=584052 .
I am not a dev and have pretty much given up. The Gentoo devs are adamant that this
is an upstream problem.
Jun 19 2016
I can't find an explanation why gentoo inserts "-hardfloat". I doubt that this
is willy-nilly and as long as this has not been figured out, there is a
possibility of a different ABI and thus we can't simply alias it. Can you
please work with Kristian or someone else from gentoo to figure this out?
Thanks for binutils link.
Again, the host is not my invention. I linked it before and I'll do it again:
Gentoo's cross-compile tool, crossdev, suggests using "-hardfloat-" and "-
softfloat-" in the vendor field.
And here is how binutils handles this (they don't shy away from asterisks):
Jun 16 2016
Is armv7a-hardfloat-linux-gnu guaranteed to be ABI compatible to some other arm
triplet? If that is the case, I suggest to either drop your(?) invention of
-hardfloat- or, better, to work with the config mainatiners to make sure it is
viewed as an alias.
How does binutils handle this triplet?
If you can describe the user base for that triplet, I may add an exception to
mkheader to get things done faster.
I'm sorry if your understanding of valid hostnames, acceptable by GNU projects, is
two decades old but this project happens to be the only one that assumes there
exists a finite list of valid hostnames without using pattern matching.
Using https://wiki.gentoo.org/wiki/Raspberry_Pi and a hostname of armv7a-
hardfloat-linux-gnu, with the notable exception of libgpg-error, I have been able
to compile and install all other GNU utilities included the core set of Gentoo
Linux, whether via the package's giving configure script or by use of autoreconf.
Hare are just a few of such GNU packages that I have personally been able to build
and install using the hostname "armv7a-hardfloat-linux-gnu":
The only other GNU package that doesn't compile for me is autogen. But that's due
to a lack of cross-compile support. It otherwise builds just fine natively on
I would appreciate it if you could provide a specific GNU package using autotools
that you assert should fail to support such a hostname, other than this one, so
that I may provide a build log demonstrating that it indeed does.
Jun 15 2016
Sorry, if _you_ want support for your _new target_ you should make sure that it
is supported by the GNU autotools which is used by a lot of software. This will
the soon be used by GnuPG etc.
It is entirely fine to point us new config versions with support for your
target. We will the update them in our packages - this is how we have done it
for close to 2 decades.
Jun 8 2016
I would except that config.sub already validates such names as 'armv7a-hardfloat-
linux-gnueabi' so there is nothing to fix. It is libgpg-error that doesn't. If
you feel it should invalidate such names please report that to the GNU config
folks instead. Their repo is at git://git.sv.gnu.org/config.git. Otherwise
pleases fix libgpg-error.
No, that is not acceptable for libgpg-error. Please report that to the GNU config
folks instead. Their repo is at git://git.sv.gnu.org/config.git
If you decide to change your mind, this patch places the logic in configure.ac.
Jun 6 2016
The host naming scheme accepted by this project is really just Debian oriented.
There is nothing saying you have to aid other distro's hostnames but I have yet to
witness a project more unfriendly to non-Debianesque distros that libgpg-error.
You don't have to accept the patch. Understandable, since mkheader would not
ideally be the way to go. But you should at least be open to the idea of
supporting the more liberal host naming schemes that other distros employ.
Jun 1 2016
Ian may have a different opinion on that (now) but the GNU build system defines
it in the way I described it.
May 27 2016
Whether or not config.sub is up to date should be irrelevant as to whether
libgpg-error should be able to handle CPU variants and the second field of a
HOST. It is supposed to be treated as a freeform field (see
http://airs.com/ian/configure/configure_4.html). As to the precision of the r.e,
it is not supposed to fix or mimic the logic of config.sub. It is to
effectively pigeonhole some HOST strings to a valid header file. Can you give me
a scenario where arm*linux-gnueabi shouldn't map to
Also, what is the source of your assertion that armv7a-hardfloat-linux-gnueabi
is not a valid canonical triplet? Everything that I have ever read about HOST
strings such as "armv7a-hardfloat-linux-gnueabi" is that configure scripts treat
them as valid and parse them with case statements (as demonstrated here
http://airs.com/ian/configure/configure_4.html). They don't demand that the
end-user pass a generic version of HOST, like "arm-unknown-linux-gnueabi". The
only reason I chose to patch mkheader.c instead or configure.ac was to build on
the mapping logic already there.
config.sub is indeed intended to canonicalize triplets. Thus a an up-to-date
config.sub should fix this. In any case you can always override the guessed
value like this:
-/configure --build=$(build-aux/config.guess) --host=arm-unknown-linux-gnueabi
I fear that a single r.e. is not precise enough; config.sub has more complicated
Mar 18 2016
There are still problems with libtool; see recent Debian problems on building
gnupg for Windows. Thus we won't chnage libtool for 1.7.0.
Nov 20 2015
Given that this bug does not appear to be reproducable with 0.9.6, I'm marking
this as resolved.
Nov 11 2015
Pretty old. We should re-evaluate this for the 1.7 release.
Nov 6 2015
Sep 22 2015
ciil: Thanks for the update!
Sep 21 2015
Sep 15 2015
Sorry for not having provided more information earlier. The bug seemed to only appear
on my work machine (and I've been to busy at work the last few weeks to provide more
information), but now I can reliably reproduce it on my home machine, too, funnily
enough after a clean re-install of Arch Linux.
It certainly seems to be the same bug as the Gentoo bug #560158 you linked. I cannot
reproduce the behavior in either gdb or valgrind, but without those the command fails
I've since downloaded and manually built 0.9.5 and 0.9.6. I could reproduce it in the
standalone 0.9.5 build (again, neither valgrind nor gdb could be coerced into also
showing the behavior. The issue seems to be fixed in 0.9.6, though! Arch doesn't yet
provide the new version as an official package. I'll tell you if the issue's also fixed
when that package comes out.
Still have no idea what caused it though.
Kristian Fiskerstrand pointed out that there is more information about this bug
Sep 11 2015
Sep 10 2015
Fixed in 1.6.4.
Aug 30 2015
Maybe add configure parameter to ignore subarch for 99% of cases in which it
does not matter? This will avoid patching in most of the cases.
I doubt that the subarch always uses the same ABI.
Aug 29 2015
Thanks, but I do not understand the comment, do you suggest to patch this file
with every subarch out there? I still trying to understand why subarch is
important for the processing, it is a generic string.
Aug 26 2015
FWIW, meanwhile there is a mapping table in src/mkheader.c:canon_host_triplet.
Aug 24 2015
Thanks for the report. I'm having trouble reproducing this. I run pinentry
(from the build directory) as follows:
$ valgrind gtk+-2/pinentry-gtk-2 ==3611== Memcheck, a memory error detector ==3611== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==3611== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==3611== Command: gtk+-2/pinentry-gtk-2 ==3611== OK Pleased to meet you getpin D 012345678901234567890 OK
I enter a 21 character password and pinentry doesn't crash and valgrind doesn't
report any error. I tried with both 0.9.5 and the latest version from git.
Are you able to reproduce the problem using the above method? Can you provide
an example of how to cause the crash using only pinentry?
Aug 21 2015
Jul 21 2015
Jul 18 2015
0003-build-sync-qt4-pkg-config-behavior-with-other-pkg-co.patch - on top
sync qt4 pkg-config behaviour
0002-build-use-pkg.m4-for-pkg-config-usage.patch - on top
remove the manual pkg-config usage, as build already use pkg.m4 macros there is
no reason to use manual pkg-config
Jun 11 2015
Thank you, patch applied to master and 1.6 branch.
May 18 2015
I tested your pkg-config patch on Debian Jessie and everything still compiles
fine. I've applied the pkg-config patch. If gentoo is now using a newer
version of this patch, please let me know. Thanks.
May 11 2015
Duplicate of T1936
[I granted you the User role (see https://bugs.gnupg.org)]
Fixed with commit 726c005 for 0.9.2.
You will now get an gpg-error codes like ENOENT, ENOTTY and GPG_ERR_TOO_SHORT
and not always GPG_ERR_CANCELED. I was not able to replicate a crash but that
might have been fixed in an earlier version.
May 9 2015
Probably, T1936 will a duplicate of this issue.
Create a new issue so I could not comment on the issue...